From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:38:31 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:38:31 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: it sends 5 bytes, \r\n are printed and the output goes on the next line as a side effect (sorry if i did not point it out). anyway the code: sh.write("1TS\r\n"); where sh.write does this: public void write(String s) throws IOException { debug(String.format(">>> %s", s)); outputStream.write(s.getBytes()); } outputStream is a bare OutputStream obtained from the serial port on the reading side i use a buffered reader to read lines, the doc states that a line is ended by \n or \r\n so it should be platform indepentent public String readLine() throws IOException { String s = reader.readLine(); debug(String.format("<<< %s", s)); return s; } reader is a BufferedReader built around the serialport input stream reader = new BufferedReader(new InputStreamReader(is)); 2010/9/15 Kustaa Nyholm > > > > > The output i reported is written by my java application when it sends and > when > > it receive. > > I still do not quite understand what happens at the code level. > > Your program outputs: > > > On linux instead i have this: > > > > 2010-09-07 12.16.40: >>> 1TS > > timeout > > 2010-09-07 12.16.42: >>> 1TS > > 2010-09-07 12.16.42: <<< 3 > > 2010-09-07 12.16.43: >>> 1TS > > timeout > > So your code sends '1TS' and then get timeout? On write? > > Why it only send three bytes, or how do you know it only sends three bytes, > what I'm trying to say is that if I had programmed this the code would look > something like: > > outstream.write(bytestosend,0,bytestosend.length); > > and thus I would not know that I've only sent three bytes. So evidently > your code is different and that's why I suggested that it might be > helpful to actually see the code. > > Or am I missing something here? > > 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 andy at g0poy.com Wed Sep 15 07:40:16 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 15 Sep 2010 14:40:16 +0100 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915144016.2630de90@g0poy-server.site> Would strace help you? I've seen some references to this particularly with the -e read=set and -e write=set options. Trouble is, that I don't fully understand strace :-( Andy On Wed, 15 Sep 2010 14:42:23 +0200 Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm > > > > > >> The protocol used is an ascii protocol with CR/LF terminator for > > messages. > > > > In Windows CR/LF is often used in line termination and this convention > > is buried in lots of code ... whereas in *nix world LF only is used. > > > > So could this be related to your issue? > > > > It could be helpful if you described how you grabbed the dump > > of what is happening, now it is unclear weather you have > > observed the communication on the PC side, or device side, or > > on the actual serial communication line. > > > > Also it might be useful to show the code that actually read/write > > the port, not just the port initialization. > > > > br Kusti > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From hybris0 at gmail.com Wed Sep 15 07:40:04 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:04 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: i was not able to get it work....it does not capture anything.... 2010/9/15 George H > On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > > The output i reported is written by my java application when it sends and > > when it receive. > > As i said under linux i do not have a powerful tool like portmon on > windows > > (funny because usually is the other way round) > > > > Will this work ? http://www.rolf-schroedter.de/moni/ > > -- > George H > george.dma at gmail.com > > > The read and write is pretty simple and is done using the streams coming > > from the serial ports and yes, after each write i do a flush, even if i > do > > not use buffered streams because i saw it must be done otherwise stuff > > remains on the pc side. > > > > > > 2010/9/15 Kustaa Nyholm > >> > >> >> The protocol used is an ascii protocol with CR/LF terminator for > >> >> messages. > >> > >> In Windows CR/LF is often used in line termination and this convention > >> is buried in lots of code ... whereas in *nix world LF only is used. > >> > >> So could this be related to your issue? > >> > >> It could be helpful if you described how you grabbed the dump > >> of what is happening, now it is unclear weather you have > >> observed the communication on the PC side, or device side, or > >> on the actual serial communication line. > >> > >> Also it might be useful to show the code that actually read/write > >> the port, not just the port initialization. > >> > >> br Kusti > >> > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:40:59 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:59 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <1CD57CB0C6974785BFAB43E383D60295@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: the device requires XON/XOFF i don't get the hint about Netbeans that, btw i am using. 2010/9/15 M.Dec-GM > And what about this problem - how it works WITHOUT XON/XOFF? > Assuming (with overhead) 12 bits per byte and 12 bytes, your > transmission duration is 2.5 ms. > If you said that system is enough fast, should find 2,5 ms in each second > to serve this packet :) > > BTW: Netbeans for Linux is very easy to install and use.... no differences > :) > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 2:48 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > I am working on a PC, no PDAs....i exclude the fact that linux is too slow. > I already used RXTX under linux with no problem at all. > Also, since i was not unable to debug the application in Linux i debugged > it in Windows running in a virtual machine under the same Linux. > > Even if XON/XOFF is so simple i keep its implementations as a last resort. > Fortunately i develop on Linux but, in this case, deploy on windows so i > can workaround it this way.... debugging is a bit tedious done this way but > the protocol is sufficiently simple to not require too much debugging. In > fact i am done with it. > > I already tried to link to the RXTX sources but it seems that the flow > control stuff is done in the C part. > > 2010/9/15 M.Dec-GMail > >> Ok, >> Have you a Java source of the application? >> >> If yes, you may do a trick, which I did when I was fighting with close() >> in Linux :) >> I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to >> the application folder. >> >> !!! >> You have to remove EACH copy of the RXTX.jar from the system, and stay >> with application sources with RXTX inside. >> !!! >> >> In this case you will have very deep access to RXTX sources >> Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF >> codes. >> >> As a final/least solution is own XON/XOFF protocoll - very simple - >> believe me :) >> I think that it will be faster to write than looking for Linux >> codes/problems. >> >> OR >> >> maybe there is a Java software mistake in Serial service which is better >> visible/more critical in Linux? >> >> Switch XON/XOFF at all and try how it works. >> You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, >> assumming 10 bytes of data + CRLF. >> >> OR >> Another idea - try to send device's XON after first query... >> >> 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - >> what the computer is this - PC or small PDA, ARM? >> >> Mariusz >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 1:56 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> The protocol is not binary and the device works only that way. >> >> I'll do some of the checks you mentioned but it seems fair to me expecting >> rxtx to behave the same way on windows and linux. >> >> I recognize that it can also be a buffer problem, or a XON/XOFF value >> problem....unfortunately linux does not offer any decent tool for sniffing >> the serial at OS level as far as i know. >> >> 2010/9/15 M.Dec-GM >> >>> Hi, >>> Using XON-XOFF software handshake protocol has a some limitations - bytes >>> for XON and for XOFF are not usable, so you shouldn't transfer binary data >>> through channel. >>> This is why I am not using this protocol at all. >>> But it isn't answer yet :) >>> >>> Maybe this helps: >>> 1. Please check if codes for XON/XOFF are identical in host and client. >>> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >>> be defined by user and I did a mistake - I have forgotten to switch >>> automatic XON/XOFF in tool, but both codes were 0x00 by default... >>> You know what it means when binary data were transmitted... crazy :). >>> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >>> only... >>> 4. Looking on the problem from another side - think if XON/XOFF is >>> necessary for now, maybe bigger buffer will be enough, or simply write >>> yourself the >>> service for XON/XOFF - this very easy, and you may use my examples for >>> this job. >>> There is enough to check XOFF in SerialReader and stop writing until XON >>> will come... >>> >>> Good luck :) >>> Mariusz >>> >>> >>> >>> >>> ----- Original Message ----- >>> *From:* Hybris >>> *To:* rxtx at qbang.org >>> *Sent:* Wednesday, September 15, 2010 12:46 PM >>> *Subject:* Re: [Rxtx] XON XOFF under linux >>> >>> Nobody can help on this? >>> >>> 2010/9/7 Hybris >>> >>>> Hi, >>>> i have a problem under Linux. >>>> I often used the library (last stable release 2.1) without any problem >>>> in this environment. >>>> >>>> Without any other clues at the moment i am blaming the fact i am >>>> talking a device that requires XON/XOFF as flow control method. A >>>> method i never used before. >>>> >>>> Under windows i have no problems, under Linux commands are received by >>>> the device but i do not get replies or i get truncated replies (log >>>> follows) >>>> >>>> I am using the seial port builtin the motherboard, no usb converters. >>>> >>>> I initialize the port this way: >>>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>>> serialPort.setInputBufferSize(256); >>>> serialPort.setOutputBufferSize(256); >>>> serialPort.enableReceiveTimeout(1000); >>>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>>> >>>> The protocol used is an ascii protocol with CR/LF terminator for >>>> messages. >>>> >>>> The output i get on windows for a cycle of request/response (one per >>>> second) is this (>>> from PC to the device, <<< from device to PC): >>>> >>>> 2010-09-07 12.18.07: <<< 1TS000033 >>>> 2010-09-07 12.18.08: >>> 1TS >>>> 2010-09-07 12.18.08: <<< 1TS000033 >>>> 2010-09-07 12.18.09: >>> 1TS >>>> 2010-09-07 12.18.09: <<< 1TS000033 >>>> 2010-09-07 12.18.10: >>> 1TS >>>> 2010-09-07 12.18.10: <<< 1TS000033 >>>> 2010-09-07 12.18.11: >>> 1TS >>>> 2010-09-07 12.18.11: <<< 1TS000033 >>>> >>>> On linux instead i have this: >>>> >>>> 2010-09-07 12.16.40: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.42: >>> 1TS >>>> 2010-09-07 12.16.42: <<< 3 >>>> 2010-09-07 12.16.43: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.45: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.47: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.49: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.51: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.53: >>> 1TS >>>> 2010-09-07 12.16.53: <<< 3 >>>> 2010-09-07 12.16.54: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.56: >>> 1TS >>>> 2010-09-07 12.16.56: <<< 1TS000033 >>>> 2010-09-07 12.16.57: >>> 1TS >>>> 2010-09-07 12.16.58: <<< 3 >>>> 2010-09-07 12.16.59: >>> 1TS >>>> timeout >>>> 2010-09-07 12.17.01: >>> 1TS >>>> timeout >>>> >>>> Any ideas? >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 15 07:55:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:55:58 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com><95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: Hi Steffen, > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports Currently I am using Windows application (USB CAN reader for my car) where is the default list of the ports (COM64 is the highest one). Additionally I am using a lot of USB dongles simultaneously (about 20, up to 4 in one of applications) and there is no way to remember which COM number has THIS dongle on laptop or on desktop or in another USB socket... The same with CAN reader... And therefore I am very happy when I see available ports only - the highest number of the COM which I have used in last weeks was COM249 :). Have you used such COM port number? :) I have had to clean registry quite often... I think that now you understand my point of view on hardcoded COM ports list :))) Regards Mariusz From tjarvi at qbang.org Wed Sep 15 07:36:32 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Sep 2010 07:36:32 -0600 (MDT) Subject: [Rxtx] JNA In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: On Wed, 15 Sep 2010, Steffen DETTMER wrote: > * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: >> Hi all, >> So - this:part looks crazy: >>> // In case of errors, list COM1 through COM9 - it is better than nothing. >>> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for > > maybe better: `a doubtful'? > >> list [...]: "it is better than nothing", >> if such list gives no useful information... >> >> Please try to connect to the port from this list.... "Better >> than nothing" is to write - No ports, List Error or something >> like that... > > Indeed the application shall have a way to notice the problem > that should never occure. Also, a better fallback probably would > be the classic port enumeration code (althrough I also dislike if > this `probing' modifies control lines of those ports; but I'm not > neutral here anyway, because I dislike such `browsing' stuff and > would prefere to be able to enter the port name to use, as used > to be on classic unices and even if the serial port happens to be > a terminal or even a FIFO, almost everything works). > > Also, it might be insufficient to present the list of currently > available serial ports, for example in a configuration dialog I > may wish to configure ports which currently are not connected. > AFAIK, this for example is simply not possible with windows > hardware device manager, because in case the USB device is not > plugged you have it in no list where you could click it; bad... > So I think a good application should allow users to specify ports > directly anyway and no such fallback would be required. > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports > usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, > so such a fallback could help the majority of users where both > registry lookup and `port probing' fail. Of course it is hard to > tell what will happen on systems of the windows users where > registry lookups fail, probably nothing will work anyway, but who > knows :) > I'd just add that laptops are the most common computer people use today and very few actually have serial ports out of the box. No ports available is a useful answer. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Sep 15 08:04:50 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 17:04:50 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > it sends 5 bytes, \r\n are printed and the output goes on the next line as a > side effect (sorry if i did not point it out). > > anyway the code: > > sh.write("1TS\r\n"); > > where sh.write does this: > > public void write(String s) throws IOException { > ??????? debug(String.format(">>> %s", s)); > ??????? outputStream.write(s.getBytes()); > } Java doc for String.getBytes() says: "Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array." Could it be that the default charset on your Linux system is different from Windows and this messes things up? > > outputStream is a bare OutputStream obtained from the serial port > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent > > public String readLine() throws IOException { > ??????? String s = reader.readLine(); > ??????? debug(String.format("<<< %s", s)); > ??????? return s; > ??? } > > reader is a BufferedReader built around the serialport input stream > reader = new BufferedReader(new InputStreamReader(is)); > > Nothing strikes me as suspicious above. But I still do not understand this, you said (for Windows): >>> 2010-09-07 12.1807: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 ' where does that '000033 come and why it is different in the Linux case? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 08:08:32 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:08:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915140832.GF7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > As i said under linux i do not have a powerful tool like portmon on > windows (funny because usually is the other way round) > The read and write is pretty simple could `strace -e open,read,write -p ' help maybe? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:12:49 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:12:49 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2><1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <05754F9E14B746D1B81F2827F7E738F6@mdam2> Sorry, but finally I don't understand... You have written: ----> the device requires XON/XOFF I know it from tenths of years, but I have checked once again: http://en.wikipedia.org/wiki/Software_flow_control Flow control is necessary when one of the communication sides can't receive data because of somewhat... So if transmission is fast and short, and machines are fast, XON/XOFF signals NEVER occurs. Execptions....? ... exception I see now as possible one is the initalisation of the transmission, but in this case YOU should try to send XON. Mariusz From hybris0 at gmail.com Wed Sep 15 08:16:48 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:16:48 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: 2010/9/15 Kustaa Nyholm > > Could it be that the default charset on your Linux system is different from > Windows and this messes things up? > > yes it could but since i use only ASCII it could not. Anyway i just tested it and the list of bytes generated is correct so the problem is not there. > But I still do not understand this, you said (for Windows): [...] > > where does that '000033 come and why it is different in the Linux case? > > 1TS000033 is the reply from the device at the command 1TS the linux case is different imho because the flow control is messing things up....but i can't prove it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:19:37 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:19:37 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <20100915141937.GG7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 15:40 +0200: > And what about this problem - how it works WITHOUT XON/XOFF? I'm not sure if I understand the question correctly, but in case it helps: If you are able to always receive full speed (e.g. because on a fine PC) and you write slowing (some Thread.Sleep(50) per each few bytes or so), you should never need to send XOFF and the device should never need to do so; maybe you need to send XON once at the begin (if device starts in XOFF) but everything else should work `transparently' in this special case (i.e. PC is receiving fast but sending slowly). You told you're working on linux; here shell console windows (xterm etc) are XON/XOFF (CTRL-Q / CTRL-S), so you know how it works: as long as you don't press CTRL-S, text scrolls through. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From hybris0 at gmail.com Wed Sep 15 08:26:58 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:26:58 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <05754F9E14B746D1B81F2827F7E738F6@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> <05754F9E14B746D1B81F2827F7E738F6@mdam2> Message-ID: i understand your point and i admit ignorance on how XON/XOFF worked.... i have to assume some things as blackboxes sometimes otherwise i'll go crazy i'll investigate further 2010/9/15 M.Dec-GM > Sorry, but finally I don't understand... > You have written: > ----> the device requires XON/XOFF > > I know it from tenths of years, but I have checked once again: > http://en.wikipedia.org/wiki/Software_flow_control > > Flow control is necessary when one of the communication sides can't receive > data because of somewhat... > So if transmission is fast and short, and machines are fast, XON/XOFF > signals NEVER occurs. > > Execptions....? > ... exception I see now as possible one is the initalisation of the > transmission, but in this case YOU should try to send XON. > > Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 08:29:08 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:29:08 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <20100915140832.GF7681@elberon.bln.de.ingenico.com> References: <20100915140832.GF7681@elberon.bln.de.ingenico.com> Message-ID: yes it could but that call also traces operation on files etc. last time i tried the output was so bloated that i gave up but i should try again 2010/9/15 Steffen DETTMER > * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > > As i said under linux i do not have a powerful tool like portmon on > > windows (funny because usually is the other way round) > > The read and write is pretty simple > > could `strace -e open,read,write -p ' help maybe? > > oki, > > Steffen > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:32:12 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:32:12 +0200 Subject: [Rxtx] JNA In-Reply-To: References: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <20100915143212.GH7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 15:55 +0200: > Additionally I am using a lot of USB dongles simultaneously > (about 20, up to 4 in one of applications) and there is no way > to remember which COM number has THIS dongle on laptop or on > desktop or in another USB socket... The same with CAN reader... > > And therefore I am very happy when I see available ports only - > the highest number of the COM which I have used in last weeks > was COM249 :). Have you used such COM port number? :) Yes, similar things happen with some USB terminals that have to reboot several time in a kind of loop for some test cases, but on linux the used device names were much more cryptic :-) Also, it even seems you can crash many PCs or their USB subsystems by pluging/unplugging and/or booting/rebooting and/or `USB-re-negiotiating' things simultanously/quickly/often enough... > I have had to clean registry quite often... > I think that now you understand my point of view on hardcoded > COM ports list :))) Yes, I do and of course you are right with your statements. I just wanted to point out that in case everything fails and the list that usually shows the available ports would be completely empty, because both methods of enumerating them failed, it could be useful in some circumstances to have then at least a list of COM1..COM10 instead of an empty one, especially in a `must not happen' case, but the application has a way to notice this of course (and I would never expect a library to perform such fallbacks unless explicitely documented - troubleshoting this would be a nightmare...). In other words, it could be considered a way to fail softer and/or to limit damage in some special cases, but as also told in this thread this should be configurable. Since the default should probably be `disabled', the whole feature is even a bit more doubtful, because in case the application is aware of this situation, it could implement a fallback (such as a text input dialog) anyway - this specific implementation surely would suit better to the applications situation. I just wanted to point out that there are situations in which a `better than nothing' fallback is suited, but I agree that this one may not being one of them (however, no need to call it with words, but the OP was even worse... but now again lets all be friends!). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:40:31 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:40:31 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: ----- Original Message ----- From: "Kustaa Nyholm" To: Sent: Wednesday, September 15, 2010 4:04 PM Subject: Re: [Rxtx] XON XOFF under linux > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent ^^^^^^ HERE may be the problem as well: "SHOULD BE" but in many cases ISN'T. Mariusz From adrian.crum at yahoo.com Wed Sep 15 08:49:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 15 Sep 2010 07:49:02 -0700 (PDT) Subject: [Rxtx] Port Discovery/Enumeration (Was: JNA) In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <582091.78813.qm@web63105.mail.re1.yahoo.com> --- On Wed, 9/15/10, Steffen DETTMER wrote: > Indeed the application shall have a way to notice the > problem > that should never occure. Also, a better fallback probably > would > be the classic port enumeration code (althrough I also > dislike if > this `probing' modifies control lines of those ports; but > I'm not > neutral here anyway, because I dislike such `browsing' > stuff and > would prefere to be able to enter the port name to use, as > used > to be on classic unices and even if the serial port happens > to be > a terminal or even a FIFO, almost everything works). Let's not forget that you can specify ports in the properties file. Automatic port discovery and enumeration is not reliable and it has bad side-effects. Improving the port discovery/enumeration code is a worthwhile goal, but in the end, a user can always specify the ports they want to use in the properties file. To me, that seems like a universally acceptable fallback method. -Adrian From hybris0 at gmail.com Wed Sep 15 08:50:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:50:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: ok guys.... now i am pissed off i developed with this thing about 4 days......compiling on linux and hell testing in windows because of this problem i managed to finish my work and happily thrown it in his box for future use under, fortunately, windows you gave me some hints, you gave me some things to think about so i take the whole stuff out of his box again, reattach all those nice connections it has and what happens it all works without changing a line of code sometimes things like this happen to me and i really do not have answers it's running now smoothly... i can't believe all the time i spent in trying to figure out what was wrong and probably i'll never know :( thanks anyway 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:18:31 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:18:31 -0400 Subject: [Rxtx] Linux build problem Message-ID: Hi I was wondering if anyone could shed some light on why I'm having the following build problem on Linux. I usually build on windows so this is a bit of a departure for me. I'm trying to build 2.2pre2 (with a few patches) but it doesn't appear like the patches are at fault here. I had a quick look through the *.in files but nothing obvious came to light. Any help would be appreciated. John Coffey $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fPIC checking if gfortran PIC flag -fPIC works... yes checking if gfortran supports -c -o file.o... yes checking whether the gfortran linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking for xcode-select... no checking java.home /usr/java/jdk1.6.0_21/jre adjusted java.home is /usr/java/jdk1.6.0_21 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.6.0_21 checking os.version 2.6.27.25-170.2.72.fc10.i686 configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:11:59] $ make /usr/java/jdk1.6.0_21/bin/javac -classpath .:/home/john/main/javacode/rxtx-devel:/home/john/main/javacode/rxtx-devel/src: -d /home/john/main/javacode/rxtx-devel/ -O -source 1.3 -target 1.3 /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortEnumerator.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortIdentifier.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortOwnershipListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Configure.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2C.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/LPRPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/NoSuchPortException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortAlreadyClosedException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortInUseException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Raw.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485Port.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXCommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXVersion.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnsupportedCommOperationException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnSupportedLoggerException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Zystem.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:138: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String IOException ex = new IOException( String.format( "Port is in use: %s ", e.currentOwner ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:164: cannot find symbol symbol : method format(java.lang.String,java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "RXTX: java %s, native %s", gnu.io.RXTXVersion.getVersion(), gnu.io.RXTXVersion.nativeGetVersion() ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:168: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "Connecting to serial port (%s)..", serialPortName ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:186: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.err.println( String.format( "IO error: %s", e.getMessage() ) ); ^ 4 errors make: *** [/home/john/main/javacode/rxtx-devel/gnu/io/CommDriver.class] Error 1 [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:12:37] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hontvari at flyordie.com Wed Sep 15 16:28:42 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Thu, 16 Sep 2010 00:28:42 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C903D25.5030301@flyordie.com> References: <4C903D25.5030301@flyordie.com> Message-ID: <4C91489A.4080304@flyordie.com> I have found a way to make it work. If the code changes flow control from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it immediately receive both the command responses and the data sent by the remote modem. It is still unclear why setting the flow control makes any difference, considering that the same procedure works in the terminal even if the terminal is set to "no flow control" or XON/XOFF flow control. On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > I want to start a data connection through a mobile phone, acting as a > modem, using AT commands. It does work in a terminal as expected. > > There is a strange behavior when I do the same thing through RXTX. The > modem should respond to the dial (ATD...) command with a CONNECT ... > message, after it successfully connected to the remote modem. It does > respond. But my code receive this message and any data the remote > modem sends only after the data transfer is completed and the modems > disconnects or after the modem temporarily goes into command state > during the session. > > There is a log below and I attached the test class which produced it. > > For the record: The phone is Siemens C55 connected through an > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > 377 Flow control: 0 > 1379 Event: Output buffer is empty (false->true) > 1380 Sent: atd+36304696729\r > 1381 Event: Output buffer is empty (false->true) > 1428 Event: Data available (false->true) > 1528 Read: atd+36304696729\r > 20758 Event: Carrier detect (false->true) > 22800 Event: Output buffer is empty (false->true) > 22800 Sent: Hello World!\r\n > 22801 Event: Output buffer is empty (false->true) > 22801 Sent: Lets go chat!\r\n > 22805 Event: Output buffer is empty (false->true) > 32802 Event: Output buffer is empty (false->true) > 32802 Sent: +++ > 32803 Event: Output buffer is empty (false->true) > 33808 Event: Data available (false->true) > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > \r\r\nOK\r\n > 35803 Event: Output buffer is empty (false->true) > 35803 Sent: ath\r > 35805 Event: Output buffer is empty (false->true) > 35860 Event: Data available (false->true) > 35962 Read: ath\r > 36266 Event: Data available (false->true) > 36367 Read: \r\nOK\r\n > 36368 Event: Carrier detect (true->false) > 37803 The End > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:50:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:50:26 -0400 Subject: [Rxtx] Linux build problem Message-ID: Fixed, sorry my bad! I had an extraneous file in my build which the auto-conf script was picking up. It's compiling now. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Sep 15 18:33:38 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 16 Sep 2010 01:33:38 +0100 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C91489A.4080304@flyordie.com> References: <4C903D25.5030301@flyordie.com> <4C91489A.4080304@flyordie.com> Message-ID: <20100916013338.2a7f78c7@g0poy-server.site> It is possible that by setting the hardware flow control it may be setting the correct conditions for the data flow to start. My first thought would be to hang a breakout box on the cable and see what (if anything) changes It would not be the first time I've found that a device set to Xon-Xoff or even no flow control needing to see the correct conditions on the hardware control lines before it would start to work correctly. windows Hyperterm is one such troublemaker, sometimes and I've never worked out what causes it, sometimes it just stops working or will not start. The only way to wake it up is to fiddle with the control lines, and eventually it starts. One company I worked for gave up recommending it as a terminal, due to the number of help calls we got, and we switched to Tera Term, and the problems went away. Andy On Thu, 16 Sep 2010 00:28:42 +0200 Hontv?ri J?zsef Levente wrote: > I have found a way to make it work. If the code changes flow control > from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it > immediately receive both the command responses and the data sent by the > remote modem. > > It is still unclear why setting the flow control makes any difference, > considering that the same procedure works in the terminal even if the > terminal is set to "no flow control" or XON/XOFF flow control. > > > On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > > I want to start a data connection through a mobile phone, acting as a > > modem, using AT commands. It does work in a terminal as expected. > > > > There is a strange behavior when I do the same thing through RXTX. The > > modem should respond to the dial (ATD...) command with a CONNECT ... > > message, after it successfully connected to the remote modem. It does > > respond. But my code receive this message and any data the remote > > modem sends only after the data transfer is completed and the modems > > disconnects or after the modem temporarily goes into command state > > during the session. > > > > There is a log below and I attached the test class which produced it. > > > > For the record: The phone is Siemens C55 connected through an > > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > > > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > 377 Flow control: 0 > > 1379 Event: Output buffer is empty (false->true) > > 1380 Sent: atd+36304696729\r > > 1381 Event: Output buffer is empty (false->true) > > 1428 Event: Data available (false->true) > > 1528 Read: atd+36304696729\r > > 20758 Event: Carrier detect (false->true) > > 22800 Event: Output buffer is empty (false->true) > > 22800 Sent: Hello World!\r\n > > 22801 Event: Output buffer is empty (false->true) > > 22801 Sent: Lets go chat!\r\n > > 22805 Event: Output buffer is empty (false->true) > > 32802 Event: Output buffer is empty (false->true) > > 32802 Sent: +++ > > 32803 Event: Output buffer is empty (false->true) > > 33808 Event: Data available (false->true) > > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > > \r\r\nOK\r\n > > 35803 Event: Output buffer is empty (false->true) > > 35803 Sent: ath\r > > 35805 Event: Output buffer is empty (false->true) > > 35860 Event: Data available (false->true) > > 35962 Read: ath\r > > 36266 Event: Data available (false->true) > > 36367 Read: \r\nOK\r\n > > 36368 Event: Carrier detect (true->false) > > 37803 The End > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:38:31 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:38:31 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: it sends 5 bytes, \r\n are printed and the output goes on the next line as a side effect (sorry if i did not point it out). anyway the code: sh.write("1TS\r\n"); where sh.write does this: public void write(String s) throws IOException { debug(String.format(">>> %s", s)); outputStream.write(s.getBytes()); } outputStream is a bare OutputStream obtained from the serial port on the reading side i use a buffered reader to read lines, the doc states that a line is ended by \n or \r\n so it should be platform indepentent public String readLine() throws IOException { String s = reader.readLine(); debug(String.format("<<< %s", s)); return s; } reader is a BufferedReader built around the serialport input stream reader = new BufferedReader(new InputStreamReader(is)); 2010/9/15 Kustaa Nyholm > > > > > The output i reported is written by my java application when it sends and > when > > it receive. > > I still do not quite understand what happens at the code level. > > Your program outputs: > > > On linux instead i have this: > > > > 2010-09-07 12.16.40: >>> 1TS > > timeout > > 2010-09-07 12.16.42: >>> 1TS > > 2010-09-07 12.16.42: <<< 3 > > 2010-09-07 12.16.43: >>> 1TS > > timeout > > So your code sends '1TS' and then get timeout? On write? > > Why it only send three bytes, or how do you know it only sends three bytes, > what I'm trying to say is that if I had programmed this the code would look > something like: > > outstream.write(bytestosend,0,bytestosend.length); > > and thus I would not know that I've only sent three bytes. So evidently > your code is different and that's why I suggested that it might be > helpful to actually see the code. > > Or am I missing something here? > > 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 andy at g0poy.com Wed Sep 15 07:40:16 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 15 Sep 2010 14:40:16 +0100 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915144016.2630de90@g0poy-server.site> Would strace help you? I've seen some references to this particularly with the -e read=set and -e write=set options. Trouble is, that I don't fully understand strace :-( Andy On Wed, 15 Sep 2010 14:42:23 +0200 Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm > > > > > >> The protocol used is an ascii protocol with CR/LF terminator for > > messages. > > > > In Windows CR/LF is often used in line termination and this convention > > is buried in lots of code ... whereas in *nix world LF only is used. > > > > So could this be related to your issue? > > > > It could be helpful if you described how you grabbed the dump > > of what is happening, now it is unclear weather you have > > observed the communication on the PC side, or device side, or > > on the actual serial communication line. > > > > Also it might be useful to show the code that actually read/write > > the port, not just the port initialization. > > > > br Kusti > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From hybris0 at gmail.com Wed Sep 15 07:40:04 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:04 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: i was not able to get it work....it does not capture anything.... 2010/9/15 George H > On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > > The output i reported is written by my java application when it sends and > > when it receive. > > As i said under linux i do not have a powerful tool like portmon on > windows > > (funny because usually is the other way round) > > > > Will this work ? http://www.rolf-schroedter.de/moni/ > > -- > George H > george.dma at gmail.com > > > The read and write is pretty simple and is done using the streams coming > > from the serial ports and yes, after each write i do a flush, even if i > do > > not use buffered streams because i saw it must be done otherwise stuff > > remains on the pc side. > > > > > > 2010/9/15 Kustaa Nyholm > >> > >> >> The protocol used is an ascii protocol with CR/LF terminator for > >> >> messages. > >> > >> In Windows CR/LF is often used in line termination and this convention > >> is buried in lots of code ... whereas in *nix world LF only is used. > >> > >> So could this be related to your issue? > >> > >> It could be helpful if you described how you grabbed the dump > >> of what is happening, now it is unclear weather you have > >> observed the communication on the PC side, or device side, or > >> on the actual serial communication line. > >> > >> Also it might be useful to show the code that actually read/write > >> the port, not just the port initialization. > >> > >> br Kusti > >> > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:40:59 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:59 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <1CD57CB0C6974785BFAB43E383D60295@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: the device requires XON/XOFF i don't get the hint about Netbeans that, btw i am using. 2010/9/15 M.Dec-GM > And what about this problem - how it works WITHOUT XON/XOFF? > Assuming (with overhead) 12 bits per byte and 12 bytes, your > transmission duration is 2.5 ms. > If you said that system is enough fast, should find 2,5 ms in each second > to serve this packet :) > > BTW: Netbeans for Linux is very easy to install and use.... no differences > :) > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 2:48 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > I am working on a PC, no PDAs....i exclude the fact that linux is too slow. > I already used RXTX under linux with no problem at all. > Also, since i was not unable to debug the application in Linux i debugged > it in Windows running in a virtual machine under the same Linux. > > Even if XON/XOFF is so simple i keep its implementations as a last resort. > Fortunately i develop on Linux but, in this case, deploy on windows so i > can workaround it this way.... debugging is a bit tedious done this way but > the protocol is sufficiently simple to not require too much debugging. In > fact i am done with it. > > I already tried to link to the RXTX sources but it seems that the flow > control stuff is done in the C part. > > 2010/9/15 M.Dec-GMail > >> Ok, >> Have you a Java source of the application? >> >> If yes, you may do a trick, which I did when I was fighting with close() >> in Linux :) >> I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to >> the application folder. >> >> !!! >> You have to remove EACH copy of the RXTX.jar from the system, and stay >> with application sources with RXTX inside. >> !!! >> >> In this case you will have very deep access to RXTX sources >> Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF >> codes. >> >> As a final/least solution is own XON/XOFF protocoll - very simple - >> believe me :) >> I think that it will be faster to write than looking for Linux >> codes/problems. >> >> OR >> >> maybe there is a Java software mistake in Serial service which is better >> visible/more critical in Linux? >> >> Switch XON/XOFF at all and try how it works. >> You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, >> assumming 10 bytes of data + CRLF. >> >> OR >> Another idea - try to send device's XON after first query... >> >> 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - >> what the computer is this - PC or small PDA, ARM? >> >> Mariusz >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 1:56 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> The protocol is not binary and the device works only that way. >> >> I'll do some of the checks you mentioned but it seems fair to me expecting >> rxtx to behave the same way on windows and linux. >> >> I recognize that it can also be a buffer problem, or a XON/XOFF value >> problem....unfortunately linux does not offer any decent tool for sniffing >> the serial at OS level as far as i know. >> >> 2010/9/15 M.Dec-GM >> >>> Hi, >>> Using XON-XOFF software handshake protocol has a some limitations - bytes >>> for XON and for XOFF are not usable, so you shouldn't transfer binary data >>> through channel. >>> This is why I am not using this protocol at all. >>> But it isn't answer yet :) >>> >>> Maybe this helps: >>> 1. Please check if codes for XON/XOFF are identical in host and client. >>> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >>> be defined by user and I did a mistake - I have forgotten to switch >>> automatic XON/XOFF in tool, but both codes were 0x00 by default... >>> You know what it means when binary data were transmitted... crazy :). >>> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >>> only... >>> 4. Looking on the problem from another side - think if XON/XOFF is >>> necessary for now, maybe bigger buffer will be enough, or simply write >>> yourself the >>> service for XON/XOFF - this very easy, and you may use my examples for >>> this job. >>> There is enough to check XOFF in SerialReader and stop writing until XON >>> will come... >>> >>> Good luck :) >>> Mariusz >>> >>> >>> >>> >>> ----- Original Message ----- >>> *From:* Hybris >>> *To:* rxtx at qbang.org >>> *Sent:* Wednesday, September 15, 2010 12:46 PM >>> *Subject:* Re: [Rxtx] XON XOFF under linux >>> >>> Nobody can help on this? >>> >>> 2010/9/7 Hybris >>> >>>> Hi, >>>> i have a problem under Linux. >>>> I often used the library (last stable release 2.1) without any problem >>>> in this environment. >>>> >>>> Without any other clues at the moment i am blaming the fact i am >>>> talking a device that requires XON/XOFF as flow control method. A >>>> method i never used before. >>>> >>>> Under windows i have no problems, under Linux commands are received by >>>> the device but i do not get replies or i get truncated replies (log >>>> follows) >>>> >>>> I am using the seial port builtin the motherboard, no usb converters. >>>> >>>> I initialize the port this way: >>>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>>> serialPort.setInputBufferSize(256); >>>> serialPort.setOutputBufferSize(256); >>>> serialPort.enableReceiveTimeout(1000); >>>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>>> >>>> The protocol used is an ascii protocol with CR/LF terminator for >>>> messages. >>>> >>>> The output i get on windows for a cycle of request/response (one per >>>> second) is this (>>> from PC to the device, <<< from device to PC): >>>> >>>> 2010-09-07 12.18.07: <<< 1TS000033 >>>> 2010-09-07 12.18.08: >>> 1TS >>>> 2010-09-07 12.18.08: <<< 1TS000033 >>>> 2010-09-07 12.18.09: >>> 1TS >>>> 2010-09-07 12.18.09: <<< 1TS000033 >>>> 2010-09-07 12.18.10: >>> 1TS >>>> 2010-09-07 12.18.10: <<< 1TS000033 >>>> 2010-09-07 12.18.11: >>> 1TS >>>> 2010-09-07 12.18.11: <<< 1TS000033 >>>> >>>> On linux instead i have this: >>>> >>>> 2010-09-07 12.16.40: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.42: >>> 1TS >>>> 2010-09-07 12.16.42: <<< 3 >>>> 2010-09-07 12.16.43: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.45: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.47: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.49: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.51: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.53: >>> 1TS >>>> 2010-09-07 12.16.53: <<< 3 >>>> 2010-09-07 12.16.54: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.56: >>> 1TS >>>> 2010-09-07 12.16.56: <<< 1TS000033 >>>> 2010-09-07 12.16.57: >>> 1TS >>>> 2010-09-07 12.16.58: <<< 3 >>>> 2010-09-07 12.16.59: >>> 1TS >>>> timeout >>>> 2010-09-07 12.17.01: >>> 1TS >>>> timeout >>>> >>>> Any ideas? >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 15 07:55:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:55:58 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com><95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: Hi Steffen, > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports Currently I am using Windows application (USB CAN reader for my car) where is the default list of the ports (COM64 is the highest one). Additionally I am using a lot of USB dongles simultaneously (about 20, up to 4 in one of applications) and there is no way to remember which COM number has THIS dongle on laptop or on desktop or in another USB socket... The same with CAN reader... And therefore I am very happy when I see available ports only - the highest number of the COM which I have used in last weeks was COM249 :). Have you used such COM port number? :) I have had to clean registry quite often... I think that now you understand my point of view on hardcoded COM ports list :))) Regards Mariusz From tjarvi at qbang.org Wed Sep 15 07:36:32 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Sep 2010 07:36:32 -0600 (MDT) Subject: [Rxtx] JNA In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: On Wed, 15 Sep 2010, Steffen DETTMER wrote: > * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: >> Hi all, >> So - this:part looks crazy: >>> // In case of errors, list COM1 through COM9 - it is better than nothing. >>> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for > > maybe better: `a doubtful'? > >> list [...]: "it is better than nothing", >> if such list gives no useful information... >> >> Please try to connect to the port from this list.... "Better >> than nothing" is to write - No ports, List Error or something >> like that... > > Indeed the application shall have a way to notice the problem > that should never occure. Also, a better fallback probably would > be the classic port enumeration code (althrough I also dislike if > this `probing' modifies control lines of those ports; but I'm not > neutral here anyway, because I dislike such `browsing' stuff and > would prefere to be able to enter the port name to use, as used > to be on classic unices and even if the serial port happens to be > a terminal or even a FIFO, almost everything works). > > Also, it might be insufficient to present the list of currently > available serial ports, for example in a configuration dialog I > may wish to configure ports which currently are not connected. > AFAIK, this for example is simply not possible with windows > hardware device manager, because in case the USB device is not > plugged you have it in no list where you could click it; bad... > So I think a good application should allow users to specify ports > directly anyway and no such fallback would be required. > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports > usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, > so such a fallback could help the majority of users where both > registry lookup and `port probing' fail. Of course it is hard to > tell what will happen on systems of the windows users where > registry lookups fail, probably nothing will work anyway, but who > knows :) > I'd just add that laptops are the most common computer people use today and very few actually have serial ports out of the box. No ports available is a useful answer. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Sep 15 08:04:50 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 17:04:50 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > it sends 5 bytes, \r\n are printed and the output goes on the next line as a > side effect (sorry if i did not point it out). > > anyway the code: > > sh.write("1TS\r\n"); > > where sh.write does this: > > public void write(String s) throws IOException { > ??????? debug(String.format(">>> %s", s)); > ??????? outputStream.write(s.getBytes()); > } Java doc for String.getBytes() says: "Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array." Could it be that the default charset on your Linux system is different from Windows and this messes things up? > > outputStream is a bare OutputStream obtained from the serial port > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent > > public String readLine() throws IOException { > ??????? String s = reader.readLine(); > ??????? debug(String.format("<<< %s", s)); > ??????? return s; > ??? } > > reader is a BufferedReader built around the serialport input stream > reader = new BufferedReader(new InputStreamReader(is)); > > Nothing strikes me as suspicious above. But I still do not understand this, you said (for Windows): >>> 2010-09-07 12.1807: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 ' where does that '000033 come and why it is different in the Linux case? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 08:08:32 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:08:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915140832.GF7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > As i said under linux i do not have a powerful tool like portmon on > windows (funny because usually is the other way round) > The read and write is pretty simple could `strace -e open,read,write -p ' help maybe? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:12:49 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:12:49 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2><1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <05754F9E14B746D1B81F2827F7E738F6@mdam2> Sorry, but finally I don't understand... You have written: ----> the device requires XON/XOFF I know it from tenths of years, but I have checked once again: http://en.wikipedia.org/wiki/Software_flow_control Flow control is necessary when one of the communication sides can't receive data because of somewhat... So if transmission is fast and short, and machines are fast, XON/XOFF signals NEVER occurs. Execptions....? ... exception I see now as possible one is the initalisation of the transmission, but in this case YOU should try to send XON. Mariusz From hybris0 at gmail.com Wed Sep 15 08:16:48 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:16:48 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: 2010/9/15 Kustaa Nyholm > > Could it be that the default charset on your Linux system is different from > Windows and this messes things up? > > yes it could but since i use only ASCII it could not. Anyway i just tested it and the list of bytes generated is correct so the problem is not there. > But I still do not understand this, you said (for Windows): [...] > > where does that '000033 come and why it is different in the Linux case? > > 1TS000033 is the reply from the device at the command 1TS the linux case is different imho because the flow control is messing things up....but i can't prove it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:19:37 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:19:37 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <20100915141937.GG7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 15:40 +0200: > And what about this problem - how it works WITHOUT XON/XOFF? I'm not sure if I understand the question correctly, but in case it helps: If you are able to always receive full speed (e.g. because on a fine PC) and you write slowing (some Thread.Sleep(50) per each few bytes or so), you should never need to send XOFF and the device should never need to do so; maybe you need to send XON once at the begin (if device starts in XOFF) but everything else should work `transparently' in this special case (i.e. PC is receiving fast but sending slowly). You told you're working on linux; here shell console windows (xterm etc) are XON/XOFF (CTRL-Q / CTRL-S), so you know how it works: as long as you don't press CTRL-S, text scrolls through. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From hybris0 at gmail.com Wed Sep 15 08:26:58 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:26:58 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <05754F9E14B746D1B81F2827F7E738F6@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> <05754F9E14B746D1B81F2827F7E738F6@mdam2> Message-ID: i understand your point and i admit ignorance on how XON/XOFF worked.... i have to assume some things as blackboxes sometimes otherwise i'll go crazy i'll investigate further 2010/9/15 M.Dec-GM > Sorry, but finally I don't understand... > You have written: > ----> the device requires XON/XOFF > > I know it from tenths of years, but I have checked once again: > http://en.wikipedia.org/wiki/Software_flow_control > > Flow control is necessary when one of the communication sides can't receive > data because of somewhat... > So if transmission is fast and short, and machines are fast, XON/XOFF > signals NEVER occurs. > > Execptions....? > ... exception I see now as possible one is the initalisation of the > transmission, but in this case YOU should try to send XON. > > Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 08:29:08 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:29:08 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <20100915140832.GF7681@elberon.bln.de.ingenico.com> References: <20100915140832.GF7681@elberon.bln.de.ingenico.com> Message-ID: yes it could but that call also traces operation on files etc. last time i tried the output was so bloated that i gave up but i should try again 2010/9/15 Steffen DETTMER > * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > > As i said under linux i do not have a powerful tool like portmon on > > windows (funny because usually is the other way round) > > The read and write is pretty simple > > could `strace -e open,read,write -p ' help maybe? > > oki, > > Steffen > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:32:12 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:32:12 +0200 Subject: [Rxtx] JNA In-Reply-To: References: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <20100915143212.GH7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 15:55 +0200: > Additionally I am using a lot of USB dongles simultaneously > (about 20, up to 4 in one of applications) and there is no way > to remember which COM number has THIS dongle on laptop or on > desktop or in another USB socket... The same with CAN reader... > > And therefore I am very happy when I see available ports only - > the highest number of the COM which I have used in last weeks > was COM249 :). Have you used such COM port number? :) Yes, similar things happen with some USB terminals that have to reboot several time in a kind of loop for some test cases, but on linux the used device names were much more cryptic :-) Also, it even seems you can crash many PCs or their USB subsystems by pluging/unplugging and/or booting/rebooting and/or `USB-re-negiotiating' things simultanously/quickly/often enough... > I have had to clean registry quite often... > I think that now you understand my point of view on hardcoded > COM ports list :))) Yes, I do and of course you are right with your statements. I just wanted to point out that in case everything fails and the list that usually shows the available ports would be completely empty, because both methods of enumerating them failed, it could be useful in some circumstances to have then at least a list of COM1..COM10 instead of an empty one, especially in a `must not happen' case, but the application has a way to notice this of course (and I would never expect a library to perform such fallbacks unless explicitely documented - troubleshoting this would be a nightmare...). In other words, it could be considered a way to fail softer and/or to limit damage in some special cases, but as also told in this thread this should be configurable. Since the default should probably be `disabled', the whole feature is even a bit more doubtful, because in case the application is aware of this situation, it could implement a fallback (such as a text input dialog) anyway - this specific implementation surely would suit better to the applications situation. I just wanted to point out that there are situations in which a `better than nothing' fallback is suited, but I agree that this one may not being one of them (however, no need to call it with words, but the OP was even worse... but now again lets all be friends!). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:40:31 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:40:31 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: ----- Original Message ----- From: "Kustaa Nyholm" To: Sent: Wednesday, September 15, 2010 4:04 PM Subject: Re: [Rxtx] XON XOFF under linux > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent ^^^^^^ HERE may be the problem as well: "SHOULD BE" but in many cases ISN'T. Mariusz From adrian.crum at yahoo.com Wed Sep 15 08:49:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 15 Sep 2010 07:49:02 -0700 (PDT) Subject: [Rxtx] Port Discovery/Enumeration (Was: JNA) In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <582091.78813.qm@web63105.mail.re1.yahoo.com> --- On Wed, 9/15/10, Steffen DETTMER wrote: > Indeed the application shall have a way to notice the > problem > that should never occure. Also, a better fallback probably > would > be the classic port enumeration code (althrough I also > dislike if > this `probing' modifies control lines of those ports; but > I'm not > neutral here anyway, because I dislike such `browsing' > stuff and > would prefere to be able to enter the port name to use, as > used > to be on classic unices and even if the serial port happens > to be > a terminal or even a FIFO, almost everything works). Let's not forget that you can specify ports in the properties file. Automatic port discovery and enumeration is not reliable and it has bad side-effects. Improving the port discovery/enumeration code is a worthwhile goal, but in the end, a user can always specify the ports they want to use in the properties file. To me, that seems like a universally acceptable fallback method. -Adrian From hybris0 at gmail.com Wed Sep 15 08:50:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:50:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: ok guys.... now i am pissed off i developed with this thing about 4 days......compiling on linux and hell testing in windows because of this problem i managed to finish my work and happily thrown it in his box for future use under, fortunately, windows you gave me some hints, you gave me some things to think about so i take the whole stuff out of his box again, reattach all those nice connections it has and what happens it all works without changing a line of code sometimes things like this happen to me and i really do not have answers it's running now smoothly... i can't believe all the time i spent in trying to figure out what was wrong and probably i'll never know :( thanks anyway 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:18:31 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:18:31 -0400 Subject: [Rxtx] Linux build problem Message-ID: Hi I was wondering if anyone could shed some light on why I'm having the following build problem on Linux. I usually build on windows so this is a bit of a departure for me. I'm trying to build 2.2pre2 (with a few patches) but it doesn't appear like the patches are at fault here. I had a quick look through the *.in files but nothing obvious came to light. Any help would be appreciated. John Coffey $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fPIC checking if gfortran PIC flag -fPIC works... yes checking if gfortran supports -c -o file.o... yes checking whether the gfortran linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking for xcode-select... no checking java.home /usr/java/jdk1.6.0_21/jre adjusted java.home is /usr/java/jdk1.6.0_21 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.6.0_21 checking os.version 2.6.27.25-170.2.72.fc10.i686 configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:11:59] $ make /usr/java/jdk1.6.0_21/bin/javac -classpath .:/home/john/main/javacode/rxtx-devel:/home/john/main/javacode/rxtx-devel/src: -d /home/john/main/javacode/rxtx-devel/ -O -source 1.3 -target 1.3 /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortEnumerator.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortIdentifier.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortOwnershipListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Configure.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2C.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/LPRPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/NoSuchPortException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortAlreadyClosedException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortInUseException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Raw.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485Port.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXCommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXVersion.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnsupportedCommOperationException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnSupportedLoggerException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Zystem.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:138: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String IOException ex = new IOException( String.format( "Port is in use: %s ", e.currentOwner ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:164: cannot find symbol symbol : method format(java.lang.String,java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "RXTX: java %s, native %s", gnu.io.RXTXVersion.getVersion(), gnu.io.RXTXVersion.nativeGetVersion() ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:168: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "Connecting to serial port (%s)..", serialPortName ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:186: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.err.println( String.format( "IO error: %s", e.getMessage() ) ); ^ 4 errors make: *** [/home/john/main/javacode/rxtx-devel/gnu/io/CommDriver.class] Error 1 [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:12:37] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hontvari at flyordie.com Wed Sep 15 16:28:42 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Thu, 16 Sep 2010 00:28:42 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C903D25.5030301@flyordie.com> References: <4C903D25.5030301@flyordie.com> Message-ID: <4C91489A.4080304@flyordie.com> I have found a way to make it work. If the code changes flow control from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it immediately receive both the command responses and the data sent by the remote modem. It is still unclear why setting the flow control makes any difference, considering that the same procedure works in the terminal even if the terminal is set to "no flow control" or XON/XOFF flow control. On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > I want to start a data connection through a mobile phone, acting as a > modem, using AT commands. It does work in a terminal as expected. > > There is a strange behavior when I do the same thing through RXTX. The > modem should respond to the dial (ATD...) command with a CONNECT ... > message, after it successfully connected to the remote modem. It does > respond. But my code receive this message and any data the remote > modem sends only after the data transfer is completed and the modems > disconnects or after the modem temporarily goes into command state > during the session. > > There is a log below and I attached the test class which produced it. > > For the record: The phone is Siemens C55 connected through an > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > 377 Flow control: 0 > 1379 Event: Output buffer is empty (false->true) > 1380 Sent: atd+36304696729\r > 1381 Event: Output buffer is empty (false->true) > 1428 Event: Data available (false->true) > 1528 Read: atd+36304696729\r > 20758 Event: Carrier detect (false->true) > 22800 Event: Output buffer is empty (false->true) > 22800 Sent: Hello World!\r\n > 22801 Event: Output buffer is empty (false->true) > 22801 Sent: Lets go chat!\r\n > 22805 Event: Output buffer is empty (false->true) > 32802 Event: Output buffer is empty (false->true) > 32802 Sent: +++ > 32803 Event: Output buffer is empty (false->true) > 33808 Event: Data available (false->true) > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > \r\r\nOK\r\n > 35803 Event: Output buffer is empty (false->true) > 35803 Sent: ath\r > 35805 Event: Output buffer is empty (false->true) > 35860 Event: Data available (false->true) > 35962 Read: ath\r > 36266 Event: Data available (false->true) > 36367 Read: \r\nOK\r\n > 36368 Event: Carrier detect (true->false) > 37803 The End > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:50:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:50:26 -0400 Subject: [Rxtx] Linux build problem Message-ID: Fixed, sorry my bad! I had an extraneous file in my build which the auto-conf script was picking up. It's compiling now. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Sep 15 18:33:38 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 16 Sep 2010 01:33:38 +0100 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C91489A.4080304@flyordie.com> References: <4C903D25.5030301@flyordie.com> <4C91489A.4080304@flyordie.com> Message-ID: <20100916013338.2a7f78c7@g0poy-server.site> It is possible that by setting the hardware flow control it may be setting the correct conditions for the data flow to start. My first thought would be to hang a breakout box on the cable and see what (if anything) changes It would not be the first time I've found that a device set to Xon-Xoff or even no flow control needing to see the correct conditions on the hardware control lines before it would start to work correctly. windows Hyperterm is one such troublemaker, sometimes and I've never worked out what causes it, sometimes it just stops working or will not start. The only way to wake it up is to fiddle with the control lines, and eventually it starts. One company I worked for gave up recommending it as a terminal, due to the number of help calls we got, and we switched to Tera Term, and the problems went away. Andy On Thu, 16 Sep 2010 00:28:42 +0200 Hontv?ri J?zsef Levente wrote: > I have found a way to make it work. If the code changes flow control > from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it > immediately receive both the command responses and the data sent by the > remote modem. > > It is still unclear why setting the flow control makes any difference, > considering that the same procedure works in the terminal even if the > terminal is set to "no flow control" or XON/XOFF flow control. > > > On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > > I want to start a data connection through a mobile phone, acting as a > > modem, using AT commands. It does work in a terminal as expected. > > > > There is a strange behavior when I do the same thing through RXTX. The > > modem should respond to the dial (ATD...) command with a CONNECT ... > > message, after it successfully connected to the remote modem. It does > > respond. But my code receive this message and any data the remote > > modem sends only after the data transfer is completed and the modems > > disconnects or after the modem temporarily goes into command state > > during the session. > > > > There is a log below and I attached the test class which produced it. > > > > For the record: The phone is Siemens C55 connected through an > > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > > > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > 377 Flow control: 0 > > 1379 Event: Output buffer is empty (false->true) > > 1380 Sent: atd+36304696729\r > > 1381 Event: Output buffer is empty (false->true) > > 1428 Event: Data available (false->true) > > 1528 Read: atd+36304696729\r > > 20758 Event: Carrier detect (false->true) > > 22800 Event: Output buffer is empty (false->true) > > 22800 Sent: Hello World!\r\n > > 22801 Event: Output buffer is empty (false->true) > > 22801 Sent: Lets go chat!\r\n > > 22805 Event: Output buffer is empty (false->true) > > 32802 Event: Output buffer is empty (false->true) > > 32802 Sent: +++ > > 32803 Event: Output buffer is empty (false->true) > > 33808 Event: Data available (false->true) > > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > > \r\r\nOK\r\n > > 35803 Event: Output buffer is empty (false->true) > > 35803 Sent: ath\r > > 35805 Event: Output buffer is empty (false->true) > > 35860 Event: Data available (false->true) > > 35962 Read: ath\r > > 36266 Event: Data available (false->true) > > 36367 Read: \r\nOK\r\n > > 36368 Event: Carrier detect (true->false) > > 37803 The End > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Sep 17 06:18:58 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 14:18:58 +0200 Subject: [Rxtx] well known disconnect and crash problem Message-ID: <201009171418.58406.lucio@sulweb.org> Hello *, I'd need a version of rxtx without the "crash on disconnect" problem. I've read a few posts claiming a java-only solution, while some other offer a patch, e.g. the one attached to bug#144. What's the best way to go? Has 2.2pre2 the same problem? @Adrian Crum: do you think the rewrite is stable enough for simple reading from a single port on Linux and Windows in a production app? Thanks in advance Lucio. From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:38:31 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:38:31 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: it sends 5 bytes, \r\n are printed and the output goes on the next line as a side effect (sorry if i did not point it out). anyway the code: sh.write("1TS\r\n"); where sh.write does this: public void write(String s) throws IOException { debug(String.format(">>> %s", s)); outputStream.write(s.getBytes()); } outputStream is a bare OutputStream obtained from the serial port on the reading side i use a buffered reader to read lines, the doc states that a line is ended by \n or \r\n so it should be platform indepentent public String readLine() throws IOException { String s = reader.readLine(); debug(String.format("<<< %s", s)); return s; } reader is a BufferedReader built around the serialport input stream reader = new BufferedReader(new InputStreamReader(is)); 2010/9/15 Kustaa Nyholm > > > > > The output i reported is written by my java application when it sends and > when > > it receive. > > I still do not quite understand what happens at the code level. > > Your program outputs: > > > On linux instead i have this: > > > > 2010-09-07 12.16.40: >>> 1TS > > timeout > > 2010-09-07 12.16.42: >>> 1TS > > 2010-09-07 12.16.42: <<< 3 > > 2010-09-07 12.16.43: >>> 1TS > > timeout > > So your code sends '1TS' and then get timeout? On write? > > Why it only send three bytes, or how do you know it only sends three bytes, > what I'm trying to say is that if I had programmed this the code would look > something like: > > outstream.write(bytestosend,0,bytestosend.length); > > and thus I would not know that I've only sent three bytes. So evidently > your code is different and that's why I suggested that it might be > helpful to actually see the code. > > Or am I missing something here? > > 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 andy at g0poy.com Wed Sep 15 07:40:16 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 15 Sep 2010 14:40:16 +0100 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915144016.2630de90@g0poy-server.site> Would strace help you? I've seen some references to this particularly with the -e read=set and -e write=set options. Trouble is, that I don't fully understand strace :-( Andy On Wed, 15 Sep 2010 14:42:23 +0200 Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm > > > > > >> The protocol used is an ascii protocol with CR/LF terminator for > > messages. > > > > In Windows CR/LF is often used in line termination and this convention > > is buried in lots of code ... whereas in *nix world LF only is used. > > > > So could this be related to your issue? > > > > It could be helpful if you described how you grabbed the dump > > of what is happening, now it is unclear weather you have > > observed the communication on the PC side, or device side, or > > on the actual serial communication line. > > > > Also it might be useful to show the code that actually read/write > > the port, not just the port initialization. > > > > br Kusti > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From hybris0 at gmail.com Wed Sep 15 07:40:04 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:04 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: i was not able to get it work....it does not capture anything.... 2010/9/15 George H > On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > > The output i reported is written by my java application when it sends and > > when it receive. > > As i said under linux i do not have a powerful tool like portmon on > windows > > (funny because usually is the other way round) > > > > Will this work ? http://www.rolf-schroedter.de/moni/ > > -- > George H > george.dma at gmail.com > > > The read and write is pretty simple and is done using the streams coming > > from the serial ports and yes, after each write i do a flush, even if i > do > > not use buffered streams because i saw it must be done otherwise stuff > > remains on the pc side. > > > > > > 2010/9/15 Kustaa Nyholm > >> > >> >> The protocol used is an ascii protocol with CR/LF terminator for > >> >> messages. > >> > >> In Windows CR/LF is often used in line termination and this convention > >> is buried in lots of code ... whereas in *nix world LF only is used. > >> > >> So could this be related to your issue? > >> > >> It could be helpful if you described how you grabbed the dump > >> of what is happening, now it is unclear weather you have > >> observed the communication on the PC side, or device side, or > >> on the actual serial communication line. > >> > >> Also it might be useful to show the code that actually read/write > >> the port, not just the port initialization. > >> > >> br Kusti > >> > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:40:59 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:59 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <1CD57CB0C6974785BFAB43E383D60295@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: the device requires XON/XOFF i don't get the hint about Netbeans that, btw i am using. 2010/9/15 M.Dec-GM > And what about this problem - how it works WITHOUT XON/XOFF? > Assuming (with overhead) 12 bits per byte and 12 bytes, your > transmission duration is 2.5 ms. > If you said that system is enough fast, should find 2,5 ms in each second > to serve this packet :) > > BTW: Netbeans for Linux is very easy to install and use.... no differences > :) > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 2:48 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > I am working on a PC, no PDAs....i exclude the fact that linux is too slow. > I already used RXTX under linux with no problem at all. > Also, since i was not unable to debug the application in Linux i debugged > it in Windows running in a virtual machine under the same Linux. > > Even if XON/XOFF is so simple i keep its implementations as a last resort. > Fortunately i develop on Linux but, in this case, deploy on windows so i > can workaround it this way.... debugging is a bit tedious done this way but > the protocol is sufficiently simple to not require too much debugging. In > fact i am done with it. > > I already tried to link to the RXTX sources but it seems that the flow > control stuff is done in the C part. > > 2010/9/15 M.Dec-GMail > >> Ok, >> Have you a Java source of the application? >> >> If yes, you may do a trick, which I did when I was fighting with close() >> in Linux :) >> I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to >> the application folder. >> >> !!! >> You have to remove EACH copy of the RXTX.jar from the system, and stay >> with application sources with RXTX inside. >> !!! >> >> In this case you will have very deep access to RXTX sources >> Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF >> codes. >> >> As a final/least solution is own XON/XOFF protocoll - very simple - >> believe me :) >> I think that it will be faster to write than looking for Linux >> codes/problems. >> >> OR >> >> maybe there is a Java software mistake in Serial service which is better >> visible/more critical in Linux? >> >> Switch XON/XOFF at all and try how it works. >> You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, >> assumming 10 bytes of data + CRLF. >> >> OR >> Another idea - try to send device's XON after first query... >> >> 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - >> what the computer is this - PC or small PDA, ARM? >> >> Mariusz >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 1:56 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> The protocol is not binary and the device works only that way. >> >> I'll do some of the checks you mentioned but it seems fair to me expecting >> rxtx to behave the same way on windows and linux. >> >> I recognize that it can also be a buffer problem, or a XON/XOFF value >> problem....unfortunately linux does not offer any decent tool for sniffing >> the serial at OS level as far as i know. >> >> 2010/9/15 M.Dec-GM >> >>> Hi, >>> Using XON-XOFF software handshake protocol has a some limitations - bytes >>> for XON and for XOFF are not usable, so you shouldn't transfer binary data >>> through channel. >>> This is why I am not using this protocol at all. >>> But it isn't answer yet :) >>> >>> Maybe this helps: >>> 1. Please check if codes for XON/XOFF are identical in host and client. >>> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >>> be defined by user and I did a mistake - I have forgotten to switch >>> automatic XON/XOFF in tool, but both codes were 0x00 by default... >>> You know what it means when binary data were transmitted... crazy :). >>> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >>> only... >>> 4. Looking on the problem from another side - think if XON/XOFF is >>> necessary for now, maybe bigger buffer will be enough, or simply write >>> yourself the >>> service for XON/XOFF - this very easy, and you may use my examples for >>> this job. >>> There is enough to check XOFF in SerialReader and stop writing until XON >>> will come... >>> >>> Good luck :) >>> Mariusz >>> >>> >>> >>> >>> ----- Original Message ----- >>> *From:* Hybris >>> *To:* rxtx at qbang.org >>> *Sent:* Wednesday, September 15, 2010 12:46 PM >>> *Subject:* Re: [Rxtx] XON XOFF under linux >>> >>> Nobody can help on this? >>> >>> 2010/9/7 Hybris >>> >>>> Hi, >>>> i have a problem under Linux. >>>> I often used the library (last stable release 2.1) without any problem >>>> in this environment. >>>> >>>> Without any other clues at the moment i am blaming the fact i am >>>> talking a device that requires XON/XOFF as flow control method. A >>>> method i never used before. >>>> >>>> Under windows i have no problems, under Linux commands are received by >>>> the device but i do not get replies or i get truncated replies (log >>>> follows) >>>> >>>> I am using the seial port builtin the motherboard, no usb converters. >>>> >>>> I initialize the port this way: >>>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>>> serialPort.setInputBufferSize(256); >>>> serialPort.setOutputBufferSize(256); >>>> serialPort.enableReceiveTimeout(1000); >>>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>>> >>>> The protocol used is an ascii protocol with CR/LF terminator for >>>> messages. >>>> >>>> The output i get on windows for a cycle of request/response (one per >>>> second) is this (>>> from PC to the device, <<< from device to PC): >>>> >>>> 2010-09-07 12.18.07: <<< 1TS000033 >>>> 2010-09-07 12.18.08: >>> 1TS >>>> 2010-09-07 12.18.08: <<< 1TS000033 >>>> 2010-09-07 12.18.09: >>> 1TS >>>> 2010-09-07 12.18.09: <<< 1TS000033 >>>> 2010-09-07 12.18.10: >>> 1TS >>>> 2010-09-07 12.18.10: <<< 1TS000033 >>>> 2010-09-07 12.18.11: >>> 1TS >>>> 2010-09-07 12.18.11: <<< 1TS000033 >>>> >>>> On linux instead i have this: >>>> >>>> 2010-09-07 12.16.40: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.42: >>> 1TS >>>> 2010-09-07 12.16.42: <<< 3 >>>> 2010-09-07 12.16.43: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.45: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.47: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.49: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.51: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.53: >>> 1TS >>>> 2010-09-07 12.16.53: <<< 3 >>>> 2010-09-07 12.16.54: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.56: >>> 1TS >>>> 2010-09-07 12.16.56: <<< 1TS000033 >>>> 2010-09-07 12.16.57: >>> 1TS >>>> 2010-09-07 12.16.58: <<< 3 >>>> 2010-09-07 12.16.59: >>> 1TS >>>> timeout >>>> 2010-09-07 12.17.01: >>> 1TS >>>> timeout >>>> >>>> Any ideas? >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 15 07:55:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:55:58 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com><95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: Hi Steffen, > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports Currently I am using Windows application (USB CAN reader for my car) where is the default list of the ports (COM64 is the highest one). Additionally I am using a lot of USB dongles simultaneously (about 20, up to 4 in one of applications) and there is no way to remember which COM number has THIS dongle on laptop or on desktop or in another USB socket... The same with CAN reader... And therefore I am very happy when I see available ports only - the highest number of the COM which I have used in last weeks was COM249 :). Have you used such COM port number? :) I have had to clean registry quite often... I think that now you understand my point of view on hardcoded COM ports list :))) Regards Mariusz From tjarvi at qbang.org Wed Sep 15 07:36:32 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Sep 2010 07:36:32 -0600 (MDT) Subject: [Rxtx] JNA In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: On Wed, 15 Sep 2010, Steffen DETTMER wrote: > * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: >> Hi all, >> So - this:part looks crazy: >>> // In case of errors, list COM1 through COM9 - it is better than nothing. >>> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for > > maybe better: `a doubtful'? > >> list [...]: "it is better than nothing", >> if such list gives no useful information... >> >> Please try to connect to the port from this list.... "Better >> than nothing" is to write - No ports, List Error or something >> like that... > > Indeed the application shall have a way to notice the problem > that should never occure. Also, a better fallback probably would > be the classic port enumeration code (althrough I also dislike if > this `probing' modifies control lines of those ports; but I'm not > neutral here anyway, because I dislike such `browsing' stuff and > would prefere to be able to enter the port name to use, as used > to be on classic unices and even if the serial port happens to be > a terminal or even a FIFO, almost everything works). > > Also, it might be insufficient to present the list of currently > available serial ports, for example in a configuration dialog I > may wish to configure ports which currently are not connected. > AFAIK, this for example is simply not possible with windows > hardware device manager, because in case the USB device is not > plugged you have it in no list where you could click it; bad... > So I think a good application should allow users to specify ports > directly anyway and no such fallback would be required. > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports > usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, > so such a fallback could help the majority of users where both > registry lookup and `port probing' fail. Of course it is hard to > tell what will happen on systems of the windows users where > registry lookups fail, probably nothing will work anyway, but who > knows :) > I'd just add that laptops are the most common computer people use today and very few actually have serial ports out of the box. No ports available is a useful answer. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Sep 15 08:04:50 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 17:04:50 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > it sends 5 bytes, \r\n are printed and the output goes on the next line as a > side effect (sorry if i did not point it out). > > anyway the code: > > sh.write("1TS\r\n"); > > where sh.write does this: > > public void write(String s) throws IOException { > ??????? debug(String.format(">>> %s", s)); > ??????? outputStream.write(s.getBytes()); > } Java doc for String.getBytes() says: "Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array." Could it be that the default charset on your Linux system is different from Windows and this messes things up? > > outputStream is a bare OutputStream obtained from the serial port > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent > > public String readLine() throws IOException { > ??????? String s = reader.readLine(); > ??????? debug(String.format("<<< %s", s)); > ??????? return s; > ??? } > > reader is a BufferedReader built around the serialport input stream > reader = new BufferedReader(new InputStreamReader(is)); > > Nothing strikes me as suspicious above. But I still do not understand this, you said (for Windows): >>> 2010-09-07 12.1807: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 ' where does that '000033 come and why it is different in the Linux case? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 08:08:32 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:08:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915140832.GF7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > As i said under linux i do not have a powerful tool like portmon on > windows (funny because usually is the other way round) > The read and write is pretty simple could `strace -e open,read,write -p ' help maybe? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:12:49 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:12:49 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2><1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <05754F9E14B746D1B81F2827F7E738F6@mdam2> Sorry, but finally I don't understand... You have written: ----> the device requires XON/XOFF I know it from tenths of years, but I have checked once again: http://en.wikipedia.org/wiki/Software_flow_control Flow control is necessary when one of the communication sides can't receive data because of somewhat... So if transmission is fast and short, and machines are fast, XON/XOFF signals NEVER occurs. Execptions....? ... exception I see now as possible one is the initalisation of the transmission, but in this case YOU should try to send XON. Mariusz From hybris0 at gmail.com Wed Sep 15 08:16:48 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:16:48 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: 2010/9/15 Kustaa Nyholm > > Could it be that the default charset on your Linux system is different from > Windows and this messes things up? > > yes it could but since i use only ASCII it could not. Anyway i just tested it and the list of bytes generated is correct so the problem is not there. > But I still do not understand this, you said (for Windows): [...] > > where does that '000033 come and why it is different in the Linux case? > > 1TS000033 is the reply from the device at the command 1TS the linux case is different imho because the flow control is messing things up....but i can't prove it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:19:37 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:19:37 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <20100915141937.GG7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 15:40 +0200: > And what about this problem - how it works WITHOUT XON/XOFF? I'm not sure if I understand the question correctly, but in case it helps: If you are able to always receive full speed (e.g. because on a fine PC) and you write slowing (some Thread.Sleep(50) per each few bytes or so), you should never need to send XOFF and the device should never need to do so; maybe you need to send XON once at the begin (if device starts in XOFF) but everything else should work `transparently' in this special case (i.e. PC is receiving fast but sending slowly). You told you're working on linux; here shell console windows (xterm etc) are XON/XOFF (CTRL-Q / CTRL-S), so you know how it works: as long as you don't press CTRL-S, text scrolls through. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From hybris0 at gmail.com Wed Sep 15 08:26:58 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:26:58 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <05754F9E14B746D1B81F2827F7E738F6@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> <05754F9E14B746D1B81F2827F7E738F6@mdam2> Message-ID: i understand your point and i admit ignorance on how XON/XOFF worked.... i have to assume some things as blackboxes sometimes otherwise i'll go crazy i'll investigate further 2010/9/15 M.Dec-GM > Sorry, but finally I don't understand... > You have written: > ----> the device requires XON/XOFF > > I know it from tenths of years, but I have checked once again: > http://en.wikipedia.org/wiki/Software_flow_control > > Flow control is necessary when one of the communication sides can't receive > data because of somewhat... > So if transmission is fast and short, and machines are fast, XON/XOFF > signals NEVER occurs. > > Execptions....? > ... exception I see now as possible one is the initalisation of the > transmission, but in this case YOU should try to send XON. > > Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 08:29:08 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:29:08 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <20100915140832.GF7681@elberon.bln.de.ingenico.com> References: <20100915140832.GF7681@elberon.bln.de.ingenico.com> Message-ID: yes it could but that call also traces operation on files etc. last time i tried the output was so bloated that i gave up but i should try again 2010/9/15 Steffen DETTMER > * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > > As i said under linux i do not have a powerful tool like portmon on > > windows (funny because usually is the other way round) > > The read and write is pretty simple > > could `strace -e open,read,write -p ' help maybe? > > oki, > > Steffen > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:32:12 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:32:12 +0200 Subject: [Rxtx] JNA In-Reply-To: References: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <20100915143212.GH7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 15:55 +0200: > Additionally I am using a lot of USB dongles simultaneously > (about 20, up to 4 in one of applications) and there is no way > to remember which COM number has THIS dongle on laptop or on > desktop or in another USB socket... The same with CAN reader... > > And therefore I am very happy when I see available ports only - > the highest number of the COM which I have used in last weeks > was COM249 :). Have you used such COM port number? :) Yes, similar things happen with some USB terminals that have to reboot several time in a kind of loop for some test cases, but on linux the used device names were much more cryptic :-) Also, it even seems you can crash many PCs or their USB subsystems by pluging/unplugging and/or booting/rebooting and/or `USB-re-negiotiating' things simultanously/quickly/often enough... > I have had to clean registry quite often... > I think that now you understand my point of view on hardcoded > COM ports list :))) Yes, I do and of course you are right with your statements. I just wanted to point out that in case everything fails and the list that usually shows the available ports would be completely empty, because both methods of enumerating them failed, it could be useful in some circumstances to have then at least a list of COM1..COM10 instead of an empty one, especially in a `must not happen' case, but the application has a way to notice this of course (and I would never expect a library to perform such fallbacks unless explicitely documented - troubleshoting this would be a nightmare...). In other words, it could be considered a way to fail softer and/or to limit damage in some special cases, but as also told in this thread this should be configurable. Since the default should probably be `disabled', the whole feature is even a bit more doubtful, because in case the application is aware of this situation, it could implement a fallback (such as a text input dialog) anyway - this specific implementation surely would suit better to the applications situation. I just wanted to point out that there are situations in which a `better than nothing' fallback is suited, but I agree that this one may not being one of them (however, no need to call it with words, but the OP was even worse... but now again lets all be friends!). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:40:31 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:40:31 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: ----- Original Message ----- From: "Kustaa Nyholm" To: Sent: Wednesday, September 15, 2010 4:04 PM Subject: Re: [Rxtx] XON XOFF under linux > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent ^^^^^^ HERE may be the problem as well: "SHOULD BE" but in many cases ISN'T. Mariusz From adrian.crum at yahoo.com Wed Sep 15 08:49:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 15 Sep 2010 07:49:02 -0700 (PDT) Subject: [Rxtx] Port Discovery/Enumeration (Was: JNA) In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <582091.78813.qm@web63105.mail.re1.yahoo.com> --- On Wed, 9/15/10, Steffen DETTMER wrote: > Indeed the application shall have a way to notice the > problem > that should never occure. Also, a better fallback probably > would > be the classic port enumeration code (althrough I also > dislike if > this `probing' modifies control lines of those ports; but > I'm not > neutral here anyway, because I dislike such `browsing' > stuff and > would prefere to be able to enter the port name to use, as > used > to be on classic unices and even if the serial port happens > to be > a terminal or even a FIFO, almost everything works). Let's not forget that you can specify ports in the properties file. Automatic port discovery and enumeration is not reliable and it has bad side-effects. Improving the port discovery/enumeration code is a worthwhile goal, but in the end, a user can always specify the ports they want to use in the properties file. To me, that seems like a universally acceptable fallback method. -Adrian From hybris0 at gmail.com Wed Sep 15 08:50:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:50:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: ok guys.... now i am pissed off i developed with this thing about 4 days......compiling on linux and hell testing in windows because of this problem i managed to finish my work and happily thrown it in his box for future use under, fortunately, windows you gave me some hints, you gave me some things to think about so i take the whole stuff out of his box again, reattach all those nice connections it has and what happens it all works without changing a line of code sometimes things like this happen to me and i really do not have answers it's running now smoothly... i can't believe all the time i spent in trying to figure out what was wrong and probably i'll never know :( thanks anyway 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:18:31 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:18:31 -0400 Subject: [Rxtx] Linux build problem Message-ID: Hi I was wondering if anyone could shed some light on why I'm having the following build problem on Linux. I usually build on windows so this is a bit of a departure for me. I'm trying to build 2.2pre2 (with a few patches) but it doesn't appear like the patches are at fault here. I had a quick look through the *.in files but nothing obvious came to light. Any help would be appreciated. John Coffey $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fPIC checking if gfortran PIC flag -fPIC works... yes checking if gfortran supports -c -o file.o... yes checking whether the gfortran linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking for xcode-select... no checking java.home /usr/java/jdk1.6.0_21/jre adjusted java.home is /usr/java/jdk1.6.0_21 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.6.0_21 checking os.version 2.6.27.25-170.2.72.fc10.i686 configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:11:59] $ make /usr/java/jdk1.6.0_21/bin/javac -classpath .:/home/john/main/javacode/rxtx-devel:/home/john/main/javacode/rxtx-devel/src: -d /home/john/main/javacode/rxtx-devel/ -O -source 1.3 -target 1.3 /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortEnumerator.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortIdentifier.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortOwnershipListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Configure.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2C.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/LPRPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/NoSuchPortException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortAlreadyClosedException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortInUseException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Raw.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485Port.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXCommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXVersion.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnsupportedCommOperationException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnSupportedLoggerException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Zystem.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:138: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String IOException ex = new IOException( String.format( "Port is in use: %s ", e.currentOwner ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:164: cannot find symbol symbol : method format(java.lang.String,java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "RXTX: java %s, native %s", gnu.io.RXTXVersion.getVersion(), gnu.io.RXTXVersion.nativeGetVersion() ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:168: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "Connecting to serial port (%s)..", serialPortName ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:186: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.err.println( String.format( "IO error: %s", e.getMessage() ) ); ^ 4 errors make: *** [/home/john/main/javacode/rxtx-devel/gnu/io/CommDriver.class] Error 1 [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:12:37] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hontvari at flyordie.com Wed Sep 15 16:28:42 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Thu, 16 Sep 2010 00:28:42 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C903D25.5030301@flyordie.com> References: <4C903D25.5030301@flyordie.com> Message-ID: <4C91489A.4080304@flyordie.com> I have found a way to make it work. If the code changes flow control from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it immediately receive both the command responses and the data sent by the remote modem. It is still unclear why setting the flow control makes any difference, considering that the same procedure works in the terminal even if the terminal is set to "no flow control" or XON/XOFF flow control. On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > I want to start a data connection through a mobile phone, acting as a > modem, using AT commands. It does work in a terminal as expected. > > There is a strange behavior when I do the same thing through RXTX. The > modem should respond to the dial (ATD...) command with a CONNECT ... > message, after it successfully connected to the remote modem. It does > respond. But my code receive this message and any data the remote > modem sends only after the data transfer is completed and the modems > disconnects or after the modem temporarily goes into command state > during the session. > > There is a log below and I attached the test class which produced it. > > For the record: The phone is Siemens C55 connected through an > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > 377 Flow control: 0 > 1379 Event: Output buffer is empty (false->true) > 1380 Sent: atd+36304696729\r > 1381 Event: Output buffer is empty (false->true) > 1428 Event: Data available (false->true) > 1528 Read: atd+36304696729\r > 20758 Event: Carrier detect (false->true) > 22800 Event: Output buffer is empty (false->true) > 22800 Sent: Hello World!\r\n > 22801 Event: Output buffer is empty (false->true) > 22801 Sent: Lets go chat!\r\n > 22805 Event: Output buffer is empty (false->true) > 32802 Event: Output buffer is empty (false->true) > 32802 Sent: +++ > 32803 Event: Output buffer is empty (false->true) > 33808 Event: Data available (false->true) > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > \r\r\nOK\r\n > 35803 Event: Output buffer is empty (false->true) > 35803 Sent: ath\r > 35805 Event: Output buffer is empty (false->true) > 35860 Event: Data available (false->true) > 35962 Read: ath\r > 36266 Event: Data available (false->true) > 36367 Read: \r\nOK\r\n > 36368 Event: Carrier detect (true->false) > 37803 The End > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:50:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:50:26 -0400 Subject: [Rxtx] Linux build problem Message-ID: Fixed, sorry my bad! I had an extraneous file in my build which the auto-conf script was picking up. It's compiling now. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Sep 15 18:33:38 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 16 Sep 2010 01:33:38 +0100 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C91489A.4080304@flyordie.com> References: <4C903D25.5030301@flyordie.com> <4C91489A.4080304@flyordie.com> Message-ID: <20100916013338.2a7f78c7@g0poy-server.site> It is possible that by setting the hardware flow control it may be setting the correct conditions for the data flow to start. My first thought would be to hang a breakout box on the cable and see what (if anything) changes It would not be the first time I've found that a device set to Xon-Xoff or even no flow control needing to see the correct conditions on the hardware control lines before it would start to work correctly. windows Hyperterm is one such troublemaker, sometimes and I've never worked out what causes it, sometimes it just stops working or will not start. The only way to wake it up is to fiddle with the control lines, and eventually it starts. One company I worked for gave up recommending it as a terminal, due to the number of help calls we got, and we switched to Tera Term, and the problems went away. Andy On Thu, 16 Sep 2010 00:28:42 +0200 Hontv?ri J?zsef Levente wrote: > I have found a way to make it work. If the code changes flow control > from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it > immediately receive both the command responses and the data sent by the > remote modem. > > It is still unclear why setting the flow control makes any difference, > considering that the same procedure works in the terminal even if the > terminal is set to "no flow control" or XON/XOFF flow control. > > > On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > > I want to start a data connection through a mobile phone, acting as a > > modem, using AT commands. It does work in a terminal as expected. > > > > There is a strange behavior when I do the same thing through RXTX. The > > modem should respond to the dial (ATD...) command with a CONNECT ... > > message, after it successfully connected to the remote modem. It does > > respond. But my code receive this message and any data the remote > > modem sends only after the data transfer is completed and the modems > > disconnects or after the modem temporarily goes into command state > > during the session. > > > > There is a log below and I attached the test class which produced it. > > > > For the record: The phone is Siemens C55 connected through an > > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > > > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > 377 Flow control: 0 > > 1379 Event: Output buffer is empty (false->true) > > 1380 Sent: atd+36304696729\r > > 1381 Event: Output buffer is empty (false->true) > > 1428 Event: Data available (false->true) > > 1528 Read: atd+36304696729\r > > 20758 Event: Carrier detect (false->true) > > 22800 Event: Output buffer is empty (false->true) > > 22800 Sent: Hello World!\r\n > > 22801 Event: Output buffer is empty (false->true) > > 22801 Sent: Lets go chat!\r\n > > 22805 Event: Output buffer is empty (false->true) > > 32802 Event: Output buffer is empty (false->true) > > 32802 Sent: +++ > > 32803 Event: Output buffer is empty (false->true) > > 33808 Event: Data available (false->true) > > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > > \r\r\nOK\r\n > > 35803 Event: Output buffer is empty (false->true) > > 35803 Sent: ath\r > > 35805 Event: Output buffer is empty (false->true) > > 35860 Event: Data available (false->true) > > 35962 Read: ath\r > > 36266 Event: Data available (false->true) > > 36367 Read: \r\nOK\r\n > > 36368 Event: Carrier detect (true->false) > > 37803 The End > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Sep 17 06:18:58 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 14:18:58 +0200 Subject: [Rxtx] well known disconnect and crash problem Message-ID: <201009171418.58406.lucio@sulweb.org> Hello *, I'd need a version of rxtx without the "crash on disconnect" problem. I've read a few posts claiming a java-only solution, while some other offer a patch, e.g. the one attached to bug#144. What's the best way to go? Has 2.2pre2 the same problem? @Adrian Crum: do you think the rewrite is stable enough for simple reading from a single port on Linux and Windows in a production app? Thanks in advance Lucio. From mariusz.dec at gmail.com Fri Sep 17 08:14:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Fri, 17 Sep 2010 16:14:29 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> Message-ID: ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 2:18 PM Subject: [Rxtx] well known disconnect and crash problem > Hello *, > > I'd need a version of rxtx without the "crash on disconnect" problem. I've At first read carefully thread "RXTX - USB disconnecting safe and fast data transfer to app" And note that there is written about RXTX and USB disconnect. There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works in many cases. Mariusz From lucio at sulweb.org Fri Sep 17 09:07:11 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 17:07:11 +0200 Subject: [Rxtx] well known disconnect and crash problem In-Reply-To: References: <201009171418.58406.lucio@sulweb.org> Message-ID: <201009171707.11477.lucio@sulweb.org> In data venerd? 17 settembre 2010 16:14:29, M.Dec-GM ha scritto: > ----- Original Message ----- > At first read carefully thread "RXTX - USB disconnecting safe and fast data > transfer to app" And note that there is written about RXTX and USB > disconnect. Sometimes I feel the general attitude on this list not being very friendly, but I can't bet, 'cause it may very well be my poor english knowledge... never mind, could you please drop me a pointer to that thread? I subscribed to this list only 2 months ago and I have no idea where to start looking for it in the list archives. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Thanks again, Lucio. From mariusz.dec at gmail.com Fri Sep 17 11:32:32 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 17 Sep 2010 19:32:32 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> <201009171707.11477.lucio@sulweb.org> Message-ID: <986039CEE912457F87F43A281ED43768@mdam2> ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 5:07 PM There are main http://mailman.qbang.org/pipermail/rxtx/2010-September/7047577.html and next one with small improvement. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Almost 100 percent probability: - YES. But you have to good understand comments inside examples to adapt it for your code!!! In some places it looks and in fact is a bit complicated but ... works. Mariusz From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:38:31 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:38:31 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: it sends 5 bytes, \r\n are printed and the output goes on the next line as a side effect (sorry if i did not point it out). anyway the code: sh.write("1TS\r\n"); where sh.write does this: public void write(String s) throws IOException { debug(String.format(">>> %s", s)); outputStream.write(s.getBytes()); } outputStream is a bare OutputStream obtained from the serial port on the reading side i use a buffered reader to read lines, the doc states that a line is ended by \n or \r\n so it should be platform indepentent public String readLine() throws IOException { String s = reader.readLine(); debug(String.format("<<< %s", s)); return s; } reader is a BufferedReader built around the serialport input stream reader = new BufferedReader(new InputStreamReader(is)); 2010/9/15 Kustaa Nyholm > > > > > The output i reported is written by my java application when it sends and > when > > it receive. > > I still do not quite understand what happens at the code level. > > Your program outputs: > > > On linux instead i have this: > > > > 2010-09-07 12.16.40: >>> 1TS > > timeout > > 2010-09-07 12.16.42: >>> 1TS > > 2010-09-07 12.16.42: <<< 3 > > 2010-09-07 12.16.43: >>> 1TS > > timeout > > So your code sends '1TS' and then get timeout? On write? > > Why it only send three bytes, or how do you know it only sends three bytes, > what I'm trying to say is that if I had programmed this the code would look > something like: > > outstream.write(bytestosend,0,bytestosend.length); > > and thus I would not know that I've only sent three bytes. So evidently > your code is different and that's why I suggested that it might be > helpful to actually see the code. > > Or am I missing something here? > > 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 andy at g0poy.com Wed Sep 15 07:40:16 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 15 Sep 2010 14:40:16 +0100 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915144016.2630de90@g0poy-server.site> Would strace help you? I've seen some references to this particularly with the -e read=set and -e write=set options. Trouble is, that I don't fully understand strace :-( Andy On Wed, 15 Sep 2010 14:42:23 +0200 Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm > > > > > >> The protocol used is an ascii protocol with CR/LF terminator for > > messages. > > > > In Windows CR/LF is often used in line termination and this convention > > is buried in lots of code ... whereas in *nix world LF only is used. > > > > So could this be related to your issue? > > > > It could be helpful if you described how you grabbed the dump > > of what is happening, now it is unclear weather you have > > observed the communication on the PC side, or device side, or > > on the actual serial communication line. > > > > Also it might be useful to show the code that actually read/write > > the port, not just the port initialization. > > > > br Kusti > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From hybris0 at gmail.com Wed Sep 15 07:40:04 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:04 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: i was not able to get it work....it does not capture anything.... 2010/9/15 George H > On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > > The output i reported is written by my java application when it sends and > > when it receive. > > As i said under linux i do not have a powerful tool like portmon on > windows > > (funny because usually is the other way round) > > > > Will this work ? http://www.rolf-schroedter.de/moni/ > > -- > George H > george.dma at gmail.com > > > The read and write is pretty simple and is done using the streams coming > > from the serial ports and yes, after each write i do a flush, even if i > do > > not use buffered streams because i saw it must be done otherwise stuff > > remains on the pc side. > > > > > > 2010/9/15 Kustaa Nyholm > >> > >> >> The protocol used is an ascii protocol with CR/LF terminator for > >> >> messages. > >> > >> In Windows CR/LF is often used in line termination and this convention > >> is buried in lots of code ... whereas in *nix world LF only is used. > >> > >> So could this be related to your issue? > >> > >> It could be helpful if you described how you grabbed the dump > >> of what is happening, now it is unclear weather you have > >> observed the communication on the PC side, or device side, or > >> on the actual serial communication line. > >> > >> Also it might be useful to show the code that actually read/write > >> the port, not just the port initialization. > >> > >> br Kusti > >> > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:40:59 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:59 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <1CD57CB0C6974785BFAB43E383D60295@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: the device requires XON/XOFF i don't get the hint about Netbeans that, btw i am using. 2010/9/15 M.Dec-GM > And what about this problem - how it works WITHOUT XON/XOFF? > Assuming (with overhead) 12 bits per byte and 12 bytes, your > transmission duration is 2.5 ms. > If you said that system is enough fast, should find 2,5 ms in each second > to serve this packet :) > > BTW: Netbeans for Linux is very easy to install and use.... no differences > :) > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 2:48 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > I am working on a PC, no PDAs....i exclude the fact that linux is too slow. > I already used RXTX under linux with no problem at all. > Also, since i was not unable to debug the application in Linux i debugged > it in Windows running in a virtual machine under the same Linux. > > Even if XON/XOFF is so simple i keep its implementations as a last resort. > Fortunately i develop on Linux but, in this case, deploy on windows so i > can workaround it this way.... debugging is a bit tedious done this way but > the protocol is sufficiently simple to not require too much debugging. In > fact i am done with it. > > I already tried to link to the RXTX sources but it seems that the flow > control stuff is done in the C part. > > 2010/9/15 M.Dec-GMail > >> Ok, >> Have you a Java source of the application? >> >> If yes, you may do a trick, which I did when I was fighting with close() >> in Linux :) >> I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to >> the application folder. >> >> !!! >> You have to remove EACH copy of the RXTX.jar from the system, and stay >> with application sources with RXTX inside. >> !!! >> >> In this case you will have very deep access to RXTX sources >> Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF >> codes. >> >> As a final/least solution is own XON/XOFF protocoll - very simple - >> believe me :) >> I think that it will be faster to write than looking for Linux >> codes/problems. >> >> OR >> >> maybe there is a Java software mistake in Serial service which is better >> visible/more critical in Linux? >> >> Switch XON/XOFF at all and try how it works. >> You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, >> assumming 10 bytes of data + CRLF. >> >> OR >> Another idea - try to send device's XON after first query... >> >> 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - >> what the computer is this - PC or small PDA, ARM? >> >> Mariusz >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 1:56 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> The protocol is not binary and the device works only that way. >> >> I'll do some of the checks you mentioned but it seems fair to me expecting >> rxtx to behave the same way on windows and linux. >> >> I recognize that it can also be a buffer problem, or a XON/XOFF value >> problem....unfortunately linux does not offer any decent tool for sniffing >> the serial at OS level as far as i know. >> >> 2010/9/15 M.Dec-GM >> >>> Hi, >>> Using XON-XOFF software handshake protocol has a some limitations - bytes >>> for XON and for XOFF are not usable, so you shouldn't transfer binary data >>> through channel. >>> This is why I am not using this protocol at all. >>> But it isn't answer yet :) >>> >>> Maybe this helps: >>> 1. Please check if codes for XON/XOFF are identical in host and client. >>> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >>> be defined by user and I did a mistake - I have forgotten to switch >>> automatic XON/XOFF in tool, but both codes were 0x00 by default... >>> You know what it means when binary data were transmitted... crazy :). >>> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >>> only... >>> 4. Looking on the problem from another side - think if XON/XOFF is >>> necessary for now, maybe bigger buffer will be enough, or simply write >>> yourself the >>> service for XON/XOFF - this very easy, and you may use my examples for >>> this job. >>> There is enough to check XOFF in SerialReader and stop writing until XON >>> will come... >>> >>> Good luck :) >>> Mariusz >>> >>> >>> >>> >>> ----- Original Message ----- >>> *From:* Hybris >>> *To:* rxtx at qbang.org >>> *Sent:* Wednesday, September 15, 2010 12:46 PM >>> *Subject:* Re: [Rxtx] XON XOFF under linux >>> >>> Nobody can help on this? >>> >>> 2010/9/7 Hybris >>> >>>> Hi, >>>> i have a problem under Linux. >>>> I often used the library (last stable release 2.1) without any problem >>>> in this environment. >>>> >>>> Without any other clues at the moment i am blaming the fact i am >>>> talking a device that requires XON/XOFF as flow control method. A >>>> method i never used before. >>>> >>>> Under windows i have no problems, under Linux commands are received by >>>> the device but i do not get replies or i get truncated replies (log >>>> follows) >>>> >>>> I am using the seial port builtin the motherboard, no usb converters. >>>> >>>> I initialize the port this way: >>>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>>> serialPort.setInputBufferSize(256); >>>> serialPort.setOutputBufferSize(256); >>>> serialPort.enableReceiveTimeout(1000); >>>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>>> >>>> The protocol used is an ascii protocol with CR/LF terminator for >>>> messages. >>>> >>>> The output i get on windows for a cycle of request/response (one per >>>> second) is this (>>> from PC to the device, <<< from device to PC): >>>> >>>> 2010-09-07 12.18.07: <<< 1TS000033 >>>> 2010-09-07 12.18.08: >>> 1TS >>>> 2010-09-07 12.18.08: <<< 1TS000033 >>>> 2010-09-07 12.18.09: >>> 1TS >>>> 2010-09-07 12.18.09: <<< 1TS000033 >>>> 2010-09-07 12.18.10: >>> 1TS >>>> 2010-09-07 12.18.10: <<< 1TS000033 >>>> 2010-09-07 12.18.11: >>> 1TS >>>> 2010-09-07 12.18.11: <<< 1TS000033 >>>> >>>> On linux instead i have this: >>>> >>>> 2010-09-07 12.16.40: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.42: >>> 1TS >>>> 2010-09-07 12.16.42: <<< 3 >>>> 2010-09-07 12.16.43: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.45: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.47: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.49: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.51: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.53: >>> 1TS >>>> 2010-09-07 12.16.53: <<< 3 >>>> 2010-09-07 12.16.54: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.56: >>> 1TS >>>> 2010-09-07 12.16.56: <<< 1TS000033 >>>> 2010-09-07 12.16.57: >>> 1TS >>>> 2010-09-07 12.16.58: <<< 3 >>>> 2010-09-07 12.16.59: >>> 1TS >>>> timeout >>>> 2010-09-07 12.17.01: >>> 1TS >>>> timeout >>>> >>>> Any ideas? >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 15 07:55:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:55:58 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com><95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: Hi Steffen, > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports Currently I am using Windows application (USB CAN reader for my car) where is the default list of the ports (COM64 is the highest one). Additionally I am using a lot of USB dongles simultaneously (about 20, up to 4 in one of applications) and there is no way to remember which COM number has THIS dongle on laptop or on desktop or in another USB socket... The same with CAN reader... And therefore I am very happy when I see available ports only - the highest number of the COM which I have used in last weeks was COM249 :). Have you used such COM port number? :) I have had to clean registry quite often... I think that now you understand my point of view on hardcoded COM ports list :))) Regards Mariusz From tjarvi at qbang.org Wed Sep 15 07:36:32 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Sep 2010 07:36:32 -0600 (MDT) Subject: [Rxtx] JNA In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: On Wed, 15 Sep 2010, Steffen DETTMER wrote: > * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: >> Hi all, >> So - this:part looks crazy: >>> // In case of errors, list COM1 through COM9 - it is better than nothing. >>> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for > > maybe better: `a doubtful'? > >> list [...]: "it is better than nothing", >> if such list gives no useful information... >> >> Please try to connect to the port from this list.... "Better >> than nothing" is to write - No ports, List Error or something >> like that... > > Indeed the application shall have a way to notice the problem > that should never occure. Also, a better fallback probably would > be the classic port enumeration code (althrough I also dislike if > this `probing' modifies control lines of those ports; but I'm not > neutral here anyway, because I dislike such `browsing' stuff and > would prefere to be able to enter the port name to use, as used > to be on classic unices and even if the serial port happens to be > a terminal or even a FIFO, almost everything works). > > Also, it might be insufficient to present the list of currently > available serial ports, for example in a configuration dialog I > may wish to configure ports which currently are not connected. > AFAIK, this for example is simply not possible with windows > hardware device manager, because in case the USB device is not > plugged you have it in no list where you could click it; bad... > So I think a good application should allow users to specify ports > directly anyway and no such fallback would be required. > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports > usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, > so such a fallback could help the majority of users where both > registry lookup and `port probing' fail. Of course it is hard to > tell what will happen on systems of the windows users where > registry lookups fail, probably nothing will work anyway, but who > knows :) > I'd just add that laptops are the most common computer people use today and very few actually have serial ports out of the box. No ports available is a useful answer. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Sep 15 08:04:50 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 17:04:50 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > it sends 5 bytes, \r\n are printed and the output goes on the next line as a > side effect (sorry if i did not point it out). > > anyway the code: > > sh.write("1TS\r\n"); > > where sh.write does this: > > public void write(String s) throws IOException { > ??????? debug(String.format(">>> %s", s)); > ??????? outputStream.write(s.getBytes()); > } Java doc for String.getBytes() says: "Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array." Could it be that the default charset on your Linux system is different from Windows and this messes things up? > > outputStream is a bare OutputStream obtained from the serial port > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent > > public String readLine() throws IOException { > ??????? String s = reader.readLine(); > ??????? debug(String.format("<<< %s", s)); > ??????? return s; > ??? } > > reader is a BufferedReader built around the serialport input stream > reader = new BufferedReader(new InputStreamReader(is)); > > Nothing strikes me as suspicious above. But I still do not understand this, you said (for Windows): >>> 2010-09-07 12.1807: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 ' where does that '000033 come and why it is different in the Linux case? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 08:08:32 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:08:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915140832.GF7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > As i said under linux i do not have a powerful tool like portmon on > windows (funny because usually is the other way round) > The read and write is pretty simple could `strace -e open,read,write -p ' help maybe? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:12:49 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:12:49 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2><1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <05754F9E14B746D1B81F2827F7E738F6@mdam2> Sorry, but finally I don't understand... You have written: ----> the device requires XON/XOFF I know it from tenths of years, but I have checked once again: http://en.wikipedia.org/wiki/Software_flow_control Flow control is necessary when one of the communication sides can't receive data because of somewhat... So if transmission is fast and short, and machines are fast, XON/XOFF signals NEVER occurs. Execptions....? ... exception I see now as possible one is the initalisation of the transmission, but in this case YOU should try to send XON. Mariusz From hybris0 at gmail.com Wed Sep 15 08:16:48 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:16:48 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: 2010/9/15 Kustaa Nyholm > > Could it be that the default charset on your Linux system is different from > Windows and this messes things up? > > yes it could but since i use only ASCII it could not. Anyway i just tested it and the list of bytes generated is correct so the problem is not there. > But I still do not understand this, you said (for Windows): [...] > > where does that '000033 come and why it is different in the Linux case? > > 1TS000033 is the reply from the device at the command 1TS the linux case is different imho because the flow control is messing things up....but i can't prove it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:19:37 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:19:37 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <20100915141937.GG7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 15:40 +0200: > And what about this problem - how it works WITHOUT XON/XOFF? I'm not sure if I understand the question correctly, but in case it helps: If you are able to always receive full speed (e.g. because on a fine PC) and you write slowing (some Thread.Sleep(50) per each few bytes or so), you should never need to send XOFF and the device should never need to do so; maybe you need to send XON once at the begin (if device starts in XOFF) but everything else should work `transparently' in this special case (i.e. PC is receiving fast but sending slowly). You told you're working on linux; here shell console windows (xterm etc) are XON/XOFF (CTRL-Q / CTRL-S), so you know how it works: as long as you don't press CTRL-S, text scrolls through. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From hybris0 at gmail.com Wed Sep 15 08:26:58 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:26:58 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <05754F9E14B746D1B81F2827F7E738F6@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> <05754F9E14B746D1B81F2827F7E738F6@mdam2> Message-ID: i understand your point and i admit ignorance on how XON/XOFF worked.... i have to assume some things as blackboxes sometimes otherwise i'll go crazy i'll investigate further 2010/9/15 M.Dec-GM > Sorry, but finally I don't understand... > You have written: > ----> the device requires XON/XOFF > > I know it from tenths of years, but I have checked once again: > http://en.wikipedia.org/wiki/Software_flow_control > > Flow control is necessary when one of the communication sides can't receive > data because of somewhat... > So if transmission is fast and short, and machines are fast, XON/XOFF > signals NEVER occurs. > > Execptions....? > ... exception I see now as possible one is the initalisation of the > transmission, but in this case YOU should try to send XON. > > Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 08:29:08 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:29:08 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <20100915140832.GF7681@elberon.bln.de.ingenico.com> References: <20100915140832.GF7681@elberon.bln.de.ingenico.com> Message-ID: yes it could but that call also traces operation on files etc. last time i tried the output was so bloated that i gave up but i should try again 2010/9/15 Steffen DETTMER > * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > > As i said under linux i do not have a powerful tool like portmon on > > windows (funny because usually is the other way round) > > The read and write is pretty simple > > could `strace -e open,read,write -p ' help maybe? > > oki, > > Steffen > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:32:12 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:32:12 +0200 Subject: [Rxtx] JNA In-Reply-To: References: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <20100915143212.GH7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 15:55 +0200: > Additionally I am using a lot of USB dongles simultaneously > (about 20, up to 4 in one of applications) and there is no way > to remember which COM number has THIS dongle on laptop or on > desktop or in another USB socket... The same with CAN reader... > > And therefore I am very happy when I see available ports only - > the highest number of the COM which I have used in last weeks > was COM249 :). Have you used such COM port number? :) Yes, similar things happen with some USB terminals that have to reboot several time in a kind of loop for some test cases, but on linux the used device names were much more cryptic :-) Also, it even seems you can crash many PCs or their USB subsystems by pluging/unplugging and/or booting/rebooting and/or `USB-re-negiotiating' things simultanously/quickly/often enough... > I have had to clean registry quite often... > I think that now you understand my point of view on hardcoded > COM ports list :))) Yes, I do and of course you are right with your statements. I just wanted to point out that in case everything fails and the list that usually shows the available ports would be completely empty, because both methods of enumerating them failed, it could be useful in some circumstances to have then at least a list of COM1..COM10 instead of an empty one, especially in a `must not happen' case, but the application has a way to notice this of course (and I would never expect a library to perform such fallbacks unless explicitely documented - troubleshoting this would be a nightmare...). In other words, it could be considered a way to fail softer and/or to limit damage in some special cases, but as also told in this thread this should be configurable. Since the default should probably be `disabled', the whole feature is even a bit more doubtful, because in case the application is aware of this situation, it could implement a fallback (such as a text input dialog) anyway - this specific implementation surely would suit better to the applications situation. I just wanted to point out that there are situations in which a `better than nothing' fallback is suited, but I agree that this one may not being one of them (however, no need to call it with words, but the OP was even worse... but now again lets all be friends!). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:40:31 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:40:31 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: ----- Original Message ----- From: "Kustaa Nyholm" To: Sent: Wednesday, September 15, 2010 4:04 PM Subject: Re: [Rxtx] XON XOFF under linux > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent ^^^^^^ HERE may be the problem as well: "SHOULD BE" but in many cases ISN'T. Mariusz From adrian.crum at yahoo.com Wed Sep 15 08:49:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 15 Sep 2010 07:49:02 -0700 (PDT) Subject: [Rxtx] Port Discovery/Enumeration (Was: JNA) In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <582091.78813.qm@web63105.mail.re1.yahoo.com> --- On Wed, 9/15/10, Steffen DETTMER wrote: > Indeed the application shall have a way to notice the > problem > that should never occure. Also, a better fallback probably > would > be the classic port enumeration code (althrough I also > dislike if > this `probing' modifies control lines of those ports; but > I'm not > neutral here anyway, because I dislike such `browsing' > stuff and > would prefere to be able to enter the port name to use, as > used > to be on classic unices and even if the serial port happens > to be > a terminal or even a FIFO, almost everything works). Let's not forget that you can specify ports in the properties file. Automatic port discovery and enumeration is not reliable and it has bad side-effects. Improving the port discovery/enumeration code is a worthwhile goal, but in the end, a user can always specify the ports they want to use in the properties file. To me, that seems like a universally acceptable fallback method. -Adrian From hybris0 at gmail.com Wed Sep 15 08:50:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:50:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: ok guys.... now i am pissed off i developed with this thing about 4 days......compiling on linux and hell testing in windows because of this problem i managed to finish my work and happily thrown it in his box for future use under, fortunately, windows you gave me some hints, you gave me some things to think about so i take the whole stuff out of his box again, reattach all those nice connections it has and what happens it all works without changing a line of code sometimes things like this happen to me and i really do not have answers it's running now smoothly... i can't believe all the time i spent in trying to figure out what was wrong and probably i'll never know :( thanks anyway 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:18:31 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:18:31 -0400 Subject: [Rxtx] Linux build problem Message-ID: Hi I was wondering if anyone could shed some light on why I'm having the following build problem on Linux. I usually build on windows so this is a bit of a departure for me. I'm trying to build 2.2pre2 (with a few patches) but it doesn't appear like the patches are at fault here. I had a quick look through the *.in files but nothing obvious came to light. Any help would be appreciated. John Coffey $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fPIC checking if gfortran PIC flag -fPIC works... yes checking if gfortran supports -c -o file.o... yes checking whether the gfortran linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking for xcode-select... no checking java.home /usr/java/jdk1.6.0_21/jre adjusted java.home is /usr/java/jdk1.6.0_21 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.6.0_21 checking os.version 2.6.27.25-170.2.72.fc10.i686 configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:11:59] $ make /usr/java/jdk1.6.0_21/bin/javac -classpath .:/home/john/main/javacode/rxtx-devel:/home/john/main/javacode/rxtx-devel/src: -d /home/john/main/javacode/rxtx-devel/ -O -source 1.3 -target 1.3 /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortEnumerator.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortIdentifier.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortOwnershipListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Configure.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2C.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/LPRPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/NoSuchPortException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortAlreadyClosedException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortInUseException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Raw.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485Port.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXCommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXVersion.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnsupportedCommOperationException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnSupportedLoggerException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Zystem.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:138: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String IOException ex = new IOException( String.format( "Port is in use: %s ", e.currentOwner ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:164: cannot find symbol symbol : method format(java.lang.String,java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "RXTX: java %s, native %s", gnu.io.RXTXVersion.getVersion(), gnu.io.RXTXVersion.nativeGetVersion() ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:168: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "Connecting to serial port (%s)..", serialPortName ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:186: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.err.println( String.format( "IO error: %s", e.getMessage() ) ); ^ 4 errors make: *** [/home/john/main/javacode/rxtx-devel/gnu/io/CommDriver.class] Error 1 [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:12:37] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hontvari at flyordie.com Wed Sep 15 16:28:42 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Thu, 16 Sep 2010 00:28:42 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C903D25.5030301@flyordie.com> References: <4C903D25.5030301@flyordie.com> Message-ID: <4C91489A.4080304@flyordie.com> I have found a way to make it work. If the code changes flow control from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it immediately receive both the command responses and the data sent by the remote modem. It is still unclear why setting the flow control makes any difference, considering that the same procedure works in the terminal even if the terminal is set to "no flow control" or XON/XOFF flow control. On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > I want to start a data connection through a mobile phone, acting as a > modem, using AT commands. It does work in a terminal as expected. > > There is a strange behavior when I do the same thing through RXTX. The > modem should respond to the dial (ATD...) command with a CONNECT ... > message, after it successfully connected to the remote modem. It does > respond. But my code receive this message and any data the remote > modem sends only after the data transfer is completed and the modems > disconnects or after the modem temporarily goes into command state > during the session. > > There is a log below and I attached the test class which produced it. > > For the record: The phone is Siemens C55 connected through an > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > 377 Flow control: 0 > 1379 Event: Output buffer is empty (false->true) > 1380 Sent: atd+36304696729\r > 1381 Event: Output buffer is empty (false->true) > 1428 Event: Data available (false->true) > 1528 Read: atd+36304696729\r > 20758 Event: Carrier detect (false->true) > 22800 Event: Output buffer is empty (false->true) > 22800 Sent: Hello World!\r\n > 22801 Event: Output buffer is empty (false->true) > 22801 Sent: Lets go chat!\r\n > 22805 Event: Output buffer is empty (false->true) > 32802 Event: Output buffer is empty (false->true) > 32802 Sent: +++ > 32803 Event: Output buffer is empty (false->true) > 33808 Event: Data available (false->true) > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > \r\r\nOK\r\n > 35803 Event: Output buffer is empty (false->true) > 35803 Sent: ath\r > 35805 Event: Output buffer is empty (false->true) > 35860 Event: Data available (false->true) > 35962 Read: ath\r > 36266 Event: Data available (false->true) > 36367 Read: \r\nOK\r\n > 36368 Event: Carrier detect (true->false) > 37803 The End > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:50:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:50:26 -0400 Subject: [Rxtx] Linux build problem Message-ID: Fixed, sorry my bad! I had an extraneous file in my build which the auto-conf script was picking up. It's compiling now. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Sep 15 18:33:38 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 16 Sep 2010 01:33:38 +0100 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C91489A.4080304@flyordie.com> References: <4C903D25.5030301@flyordie.com> <4C91489A.4080304@flyordie.com> Message-ID: <20100916013338.2a7f78c7@g0poy-server.site> It is possible that by setting the hardware flow control it may be setting the correct conditions for the data flow to start. My first thought would be to hang a breakout box on the cable and see what (if anything) changes It would not be the first time I've found that a device set to Xon-Xoff or even no flow control needing to see the correct conditions on the hardware control lines before it would start to work correctly. windows Hyperterm is one such troublemaker, sometimes and I've never worked out what causes it, sometimes it just stops working or will not start. The only way to wake it up is to fiddle with the control lines, and eventually it starts. One company I worked for gave up recommending it as a terminal, due to the number of help calls we got, and we switched to Tera Term, and the problems went away. Andy On Thu, 16 Sep 2010 00:28:42 +0200 Hontv?ri J?zsef Levente wrote: > I have found a way to make it work. If the code changes flow control > from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it > immediately receive both the command responses and the data sent by the > remote modem. > > It is still unclear why setting the flow control makes any difference, > considering that the same procedure works in the terminal even if the > terminal is set to "no flow control" or XON/XOFF flow control. > > > On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > > I want to start a data connection through a mobile phone, acting as a > > modem, using AT commands. It does work in a terminal as expected. > > > > There is a strange behavior when I do the same thing through RXTX. The > > modem should respond to the dial (ATD...) command with a CONNECT ... > > message, after it successfully connected to the remote modem. It does > > respond. But my code receive this message and any data the remote > > modem sends only after the data transfer is completed and the modems > > disconnects or after the modem temporarily goes into command state > > during the session. > > > > There is a log below and I attached the test class which produced it. > > > > For the record: The phone is Siemens C55 connected through an > > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > > > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > 377 Flow control: 0 > > 1379 Event: Output buffer is empty (false->true) > > 1380 Sent: atd+36304696729\r > > 1381 Event: Output buffer is empty (false->true) > > 1428 Event: Data available (false->true) > > 1528 Read: atd+36304696729\r > > 20758 Event: Carrier detect (false->true) > > 22800 Event: Output buffer is empty (false->true) > > 22800 Sent: Hello World!\r\n > > 22801 Event: Output buffer is empty (false->true) > > 22801 Sent: Lets go chat!\r\n > > 22805 Event: Output buffer is empty (false->true) > > 32802 Event: Output buffer is empty (false->true) > > 32802 Sent: +++ > > 32803 Event: Output buffer is empty (false->true) > > 33808 Event: Data available (false->true) > > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > > \r\r\nOK\r\n > > 35803 Event: Output buffer is empty (false->true) > > 35803 Sent: ath\r > > 35805 Event: Output buffer is empty (false->true) > > 35860 Event: Data available (false->true) > > 35962 Read: ath\r > > 36266 Event: Data available (false->true) > > 36367 Read: \r\nOK\r\n > > 36368 Event: Carrier detect (true->false) > > 37803 The End > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Sep 17 06:18:58 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 14:18:58 +0200 Subject: [Rxtx] well known disconnect and crash problem Message-ID: <201009171418.58406.lucio@sulweb.org> Hello *, I'd need a version of rxtx without the "crash on disconnect" problem. I've read a few posts claiming a java-only solution, while some other offer a patch, e.g. the one attached to bug#144. What's the best way to go? Has 2.2pre2 the same problem? @Adrian Crum: do you think the rewrite is stable enough for simple reading from a single port on Linux and Windows in a production app? Thanks in advance Lucio. From mariusz.dec at gmail.com Fri Sep 17 08:14:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Fri, 17 Sep 2010 16:14:29 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> Message-ID: ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 2:18 PM Subject: [Rxtx] well known disconnect and crash problem > Hello *, > > I'd need a version of rxtx without the "crash on disconnect" problem. I've At first read carefully thread "RXTX - USB disconnecting safe and fast data transfer to app" And note that there is written about RXTX and USB disconnect. There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works in many cases. Mariusz From lucio at sulweb.org Fri Sep 17 09:07:11 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 17:07:11 +0200 Subject: [Rxtx] well known disconnect and crash problem In-Reply-To: References: <201009171418.58406.lucio@sulweb.org> Message-ID: <201009171707.11477.lucio@sulweb.org> In data venerd? 17 settembre 2010 16:14:29, M.Dec-GM ha scritto: > ----- Original Message ----- > At first read carefully thread "RXTX - USB disconnecting safe and fast data > transfer to app" And note that there is written about RXTX and USB > disconnect. Sometimes I feel the general attitude on this list not being very friendly, but I can't bet, 'cause it may very well be my poor english knowledge... never mind, could you please drop me a pointer to that thread? I subscribed to this list only 2 months ago and I have no idea where to start looking for it in the list archives. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Thanks again, Lucio. From mariusz.dec at gmail.com Fri Sep 17 11:32:32 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 17 Sep 2010 19:32:32 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> <201009171707.11477.lucio@sulweb.org> Message-ID: <986039CEE912457F87F43A281ED43768@mdam2> ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 5:07 PM There are main http://mailman.qbang.org/pipermail/rxtx/2010-September/7047577.html and next one with small improvement. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Almost 100 percent probability: - YES. But you have to good understand comments inside examples to adapt it for your code!!! In some places it looks and in fact is a bit complicated but ... works. Mariusz From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:38:31 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:38:31 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: it sends 5 bytes, \r\n are printed and the output goes on the next line as a side effect (sorry if i did not point it out). anyway the code: sh.write("1TS\r\n"); where sh.write does this: public void write(String s) throws IOException { debug(String.format(">>> %s", s)); outputStream.write(s.getBytes()); } outputStream is a bare OutputStream obtained from the serial port on the reading side i use a buffered reader to read lines, the doc states that a line is ended by \n or \r\n so it should be platform indepentent public String readLine() throws IOException { String s = reader.readLine(); debug(String.format("<<< %s", s)); return s; } reader is a BufferedReader built around the serialport input stream reader = new BufferedReader(new InputStreamReader(is)); 2010/9/15 Kustaa Nyholm > > > > > The output i reported is written by my java application when it sends and > when > > it receive. > > I still do not quite understand what happens at the code level. > > Your program outputs: > > > On linux instead i have this: > > > > 2010-09-07 12.16.40: >>> 1TS > > timeout > > 2010-09-07 12.16.42: >>> 1TS > > 2010-09-07 12.16.42: <<< 3 > > 2010-09-07 12.16.43: >>> 1TS > > timeout > > So your code sends '1TS' and then get timeout? On write? > > Why it only send three bytes, or how do you know it only sends three bytes, > what I'm trying to say is that if I had programmed this the code would look > something like: > > outstream.write(bytestosend,0,bytestosend.length); > > and thus I would not know that I've only sent three bytes. So evidently > your code is different and that's why I suggested that it might be > helpful to actually see the code. > > Or am I missing something here? > > 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 andy at g0poy.com Wed Sep 15 07:40:16 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 15 Sep 2010 14:40:16 +0100 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915144016.2630de90@g0poy-server.site> Would strace help you? I've seen some references to this particularly with the -e read=set and -e write=set options. Trouble is, that I don't fully understand strace :-( Andy On Wed, 15 Sep 2010 14:42:23 +0200 Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm > > > > > >> The protocol used is an ascii protocol with CR/LF terminator for > > messages. > > > > In Windows CR/LF is often used in line termination and this convention > > is buried in lots of code ... whereas in *nix world LF only is used. > > > > So could this be related to your issue? > > > > It could be helpful if you described how you grabbed the dump > > of what is happening, now it is unclear weather you have > > observed the communication on the PC side, or device side, or > > on the actual serial communication line. > > > > Also it might be useful to show the code that actually read/write > > the port, not just the port initialization. > > > > br Kusti > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From hybris0 at gmail.com Wed Sep 15 07:40:04 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:04 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: i was not able to get it work....it does not capture anything.... 2010/9/15 George H > On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > > The output i reported is written by my java application when it sends and > > when it receive. > > As i said under linux i do not have a powerful tool like portmon on > windows > > (funny because usually is the other way round) > > > > Will this work ? http://www.rolf-schroedter.de/moni/ > > -- > George H > george.dma at gmail.com > > > The read and write is pretty simple and is done using the streams coming > > from the serial ports and yes, after each write i do a flush, even if i > do > > not use buffered streams because i saw it must be done otherwise stuff > > remains on the pc side. > > > > > > 2010/9/15 Kustaa Nyholm > >> > >> >> The protocol used is an ascii protocol with CR/LF terminator for > >> >> messages. > >> > >> In Windows CR/LF is often used in line termination and this convention > >> is buried in lots of code ... whereas in *nix world LF only is used. > >> > >> So could this be related to your issue? > >> > >> It could be helpful if you described how you grabbed the dump > >> of what is happening, now it is unclear weather you have > >> observed the communication on the PC side, or device side, or > >> on the actual serial communication line. > >> > >> Also it might be useful to show the code that actually read/write > >> the port, not just the port initialization. > >> > >> br Kusti > >> > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:40:59 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:59 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <1CD57CB0C6974785BFAB43E383D60295@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: the device requires XON/XOFF i don't get the hint about Netbeans that, btw i am using. 2010/9/15 M.Dec-GM > And what about this problem - how it works WITHOUT XON/XOFF? > Assuming (with overhead) 12 bits per byte and 12 bytes, your > transmission duration is 2.5 ms. > If you said that system is enough fast, should find 2,5 ms in each second > to serve this packet :) > > BTW: Netbeans for Linux is very easy to install and use.... no differences > :) > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 2:48 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > I am working on a PC, no PDAs....i exclude the fact that linux is too slow. > I already used RXTX under linux with no problem at all. > Also, since i was not unable to debug the application in Linux i debugged > it in Windows running in a virtual machine under the same Linux. > > Even if XON/XOFF is so simple i keep its implementations as a last resort. > Fortunately i develop on Linux but, in this case, deploy on windows so i > can workaround it this way.... debugging is a bit tedious done this way but > the protocol is sufficiently simple to not require too much debugging. In > fact i am done with it. > > I already tried to link to the RXTX sources but it seems that the flow > control stuff is done in the C part. > > 2010/9/15 M.Dec-GMail > >> Ok, >> Have you a Java source of the application? >> >> If yes, you may do a trick, which I did when I was fighting with close() >> in Linux :) >> I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to >> the application folder. >> >> !!! >> You have to remove EACH copy of the RXTX.jar from the system, and stay >> with application sources with RXTX inside. >> !!! >> >> In this case you will have very deep access to RXTX sources >> Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF >> codes. >> >> As a final/least solution is own XON/XOFF protocoll - very simple - >> believe me :) >> I think that it will be faster to write than looking for Linux >> codes/problems. >> >> OR >> >> maybe there is a Java software mistake in Serial service which is better >> visible/more critical in Linux? >> >> Switch XON/XOFF at all and try how it works. >> You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, >> assumming 10 bytes of data + CRLF. >> >> OR >> Another idea - try to send device's XON after first query... >> >> 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - >> what the computer is this - PC or small PDA, ARM? >> >> Mariusz >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 1:56 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> The protocol is not binary and the device works only that way. >> >> I'll do some of the checks you mentioned but it seems fair to me expecting >> rxtx to behave the same way on windows and linux. >> >> I recognize that it can also be a buffer problem, or a XON/XOFF value >> problem....unfortunately linux does not offer any decent tool for sniffing >> the serial at OS level as far as i know. >> >> 2010/9/15 M.Dec-GM >> >>> Hi, >>> Using XON-XOFF software handshake protocol has a some limitations - bytes >>> for XON and for XOFF are not usable, so you shouldn't transfer binary data >>> through channel. >>> This is why I am not using this protocol at all. >>> But it isn't answer yet :) >>> >>> Maybe this helps: >>> 1. Please check if codes for XON/XOFF are identical in host and client. >>> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >>> be defined by user and I did a mistake - I have forgotten to switch >>> automatic XON/XOFF in tool, but both codes were 0x00 by default... >>> You know what it means when binary data were transmitted... crazy :). >>> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >>> only... >>> 4. Looking on the problem from another side - think if XON/XOFF is >>> necessary for now, maybe bigger buffer will be enough, or simply write >>> yourself the >>> service for XON/XOFF - this very easy, and you may use my examples for >>> this job. >>> There is enough to check XOFF in SerialReader and stop writing until XON >>> will come... >>> >>> Good luck :) >>> Mariusz >>> >>> >>> >>> >>> ----- Original Message ----- >>> *From:* Hybris >>> *To:* rxtx at qbang.org >>> *Sent:* Wednesday, September 15, 2010 12:46 PM >>> *Subject:* Re: [Rxtx] XON XOFF under linux >>> >>> Nobody can help on this? >>> >>> 2010/9/7 Hybris >>> >>>> Hi, >>>> i have a problem under Linux. >>>> I often used the library (last stable release 2.1) without any problem >>>> in this environment. >>>> >>>> Without any other clues at the moment i am blaming the fact i am >>>> talking a device that requires XON/XOFF as flow control method. A >>>> method i never used before. >>>> >>>> Under windows i have no problems, under Linux commands are received by >>>> the device but i do not get replies or i get truncated replies (log >>>> follows) >>>> >>>> I am using the seial port builtin the motherboard, no usb converters. >>>> >>>> I initialize the port this way: >>>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>>> serialPort.setInputBufferSize(256); >>>> serialPort.setOutputBufferSize(256); >>>> serialPort.enableReceiveTimeout(1000); >>>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>>> >>>> The protocol used is an ascii protocol with CR/LF terminator for >>>> messages. >>>> >>>> The output i get on windows for a cycle of request/response (one per >>>> second) is this (>>> from PC to the device, <<< from device to PC): >>>> >>>> 2010-09-07 12.18.07: <<< 1TS000033 >>>> 2010-09-07 12.18.08: >>> 1TS >>>> 2010-09-07 12.18.08: <<< 1TS000033 >>>> 2010-09-07 12.18.09: >>> 1TS >>>> 2010-09-07 12.18.09: <<< 1TS000033 >>>> 2010-09-07 12.18.10: >>> 1TS >>>> 2010-09-07 12.18.10: <<< 1TS000033 >>>> 2010-09-07 12.18.11: >>> 1TS >>>> 2010-09-07 12.18.11: <<< 1TS000033 >>>> >>>> On linux instead i have this: >>>> >>>> 2010-09-07 12.16.40: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.42: >>> 1TS >>>> 2010-09-07 12.16.42: <<< 3 >>>> 2010-09-07 12.16.43: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.45: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.47: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.49: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.51: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.53: >>> 1TS >>>> 2010-09-07 12.16.53: <<< 3 >>>> 2010-09-07 12.16.54: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.56: >>> 1TS >>>> 2010-09-07 12.16.56: <<< 1TS000033 >>>> 2010-09-07 12.16.57: >>> 1TS >>>> 2010-09-07 12.16.58: <<< 3 >>>> 2010-09-07 12.16.59: >>> 1TS >>>> timeout >>>> 2010-09-07 12.17.01: >>> 1TS >>>> timeout >>>> >>>> Any ideas? >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 15 07:55:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:55:58 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com><95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: Hi Steffen, > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports Currently I am using Windows application (USB CAN reader for my car) where is the default list of the ports (COM64 is the highest one). Additionally I am using a lot of USB dongles simultaneously (about 20, up to 4 in one of applications) and there is no way to remember which COM number has THIS dongle on laptop or on desktop or in another USB socket... The same with CAN reader... And therefore I am very happy when I see available ports only - the highest number of the COM which I have used in last weeks was COM249 :). Have you used such COM port number? :) I have had to clean registry quite often... I think that now you understand my point of view on hardcoded COM ports list :))) Regards Mariusz From tjarvi at qbang.org Wed Sep 15 07:36:32 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Sep 2010 07:36:32 -0600 (MDT) Subject: [Rxtx] JNA In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: On Wed, 15 Sep 2010, Steffen DETTMER wrote: > * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: >> Hi all, >> So - this:part looks crazy: >>> // In case of errors, list COM1 through COM9 - it is better than nothing. >>> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for > > maybe better: `a doubtful'? > >> list [...]: "it is better than nothing", >> if such list gives no useful information... >> >> Please try to connect to the port from this list.... "Better >> than nothing" is to write - No ports, List Error or something >> like that... > > Indeed the application shall have a way to notice the problem > that should never occure. Also, a better fallback probably would > be the classic port enumeration code (althrough I also dislike if > this `probing' modifies control lines of those ports; but I'm not > neutral here anyway, because I dislike such `browsing' stuff and > would prefere to be able to enter the port name to use, as used > to be on classic unices and even if the serial port happens to be > a terminal or even a FIFO, almost everything works). > > Also, it might be insufficient to present the list of currently > available serial ports, for example in a configuration dialog I > may wish to configure ports which currently are not connected. > AFAIK, this for example is simply not possible with windows > hardware device manager, because in case the USB device is not > plugged you have it in no list where you could click it; bad... > So I think a good application should allow users to specify ports > directly anyway and no such fallback would be required. > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports > usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, > so such a fallback could help the majority of users where both > registry lookup and `port probing' fail. Of course it is hard to > tell what will happen on systems of the windows users where > registry lookups fail, probably nothing will work anyway, but who > knows :) > I'd just add that laptops are the most common computer people use today and very few actually have serial ports out of the box. No ports available is a useful answer. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Sep 15 08:04:50 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 17:04:50 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > it sends 5 bytes, \r\n are printed and the output goes on the next line as a > side effect (sorry if i did not point it out). > > anyway the code: > > sh.write("1TS\r\n"); > > where sh.write does this: > > public void write(String s) throws IOException { > ??????? debug(String.format(">>> %s", s)); > ??????? outputStream.write(s.getBytes()); > } Java doc for String.getBytes() says: "Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array." Could it be that the default charset on your Linux system is different from Windows and this messes things up? > > outputStream is a bare OutputStream obtained from the serial port > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent > > public String readLine() throws IOException { > ??????? String s = reader.readLine(); > ??????? debug(String.format("<<< %s", s)); > ??????? return s; > ??? } > > reader is a BufferedReader built around the serialport input stream > reader = new BufferedReader(new InputStreamReader(is)); > > Nothing strikes me as suspicious above. But I still do not understand this, you said (for Windows): >>> 2010-09-07 12.1807: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 ' where does that '000033 come and why it is different in the Linux case? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 08:08:32 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:08:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915140832.GF7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > As i said under linux i do not have a powerful tool like portmon on > windows (funny because usually is the other way round) > The read and write is pretty simple could `strace -e open,read,write -p ' help maybe? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:12:49 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:12:49 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2><1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <05754F9E14B746D1B81F2827F7E738F6@mdam2> Sorry, but finally I don't understand... You have written: ----> the device requires XON/XOFF I know it from tenths of years, but I have checked once again: http://en.wikipedia.org/wiki/Software_flow_control Flow control is necessary when one of the communication sides can't receive data because of somewhat... So if transmission is fast and short, and machines are fast, XON/XOFF signals NEVER occurs. Execptions....? ... exception I see now as possible one is the initalisation of the transmission, but in this case YOU should try to send XON. Mariusz From hybris0 at gmail.com Wed Sep 15 08:16:48 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:16:48 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: 2010/9/15 Kustaa Nyholm > > Could it be that the default charset on your Linux system is different from > Windows and this messes things up? > > yes it could but since i use only ASCII it could not. Anyway i just tested it and the list of bytes generated is correct so the problem is not there. > But I still do not understand this, you said (for Windows): [...] > > where does that '000033 come and why it is different in the Linux case? > > 1TS000033 is the reply from the device at the command 1TS the linux case is different imho because the flow control is messing things up....but i can't prove it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:19:37 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:19:37 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <20100915141937.GG7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 15:40 +0200: > And what about this problem - how it works WITHOUT XON/XOFF? I'm not sure if I understand the question correctly, but in case it helps: If you are able to always receive full speed (e.g. because on a fine PC) and you write slowing (some Thread.Sleep(50) per each few bytes or so), you should never need to send XOFF and the device should never need to do so; maybe you need to send XON once at the begin (if device starts in XOFF) but everything else should work `transparently' in this special case (i.e. PC is receiving fast but sending slowly). You told you're working on linux; here shell console windows (xterm etc) are XON/XOFF (CTRL-Q / CTRL-S), so you know how it works: as long as you don't press CTRL-S, text scrolls through. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From hybris0 at gmail.com Wed Sep 15 08:26:58 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:26:58 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <05754F9E14B746D1B81F2827F7E738F6@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> <05754F9E14B746D1B81F2827F7E738F6@mdam2> Message-ID: i understand your point and i admit ignorance on how XON/XOFF worked.... i have to assume some things as blackboxes sometimes otherwise i'll go crazy i'll investigate further 2010/9/15 M.Dec-GM > Sorry, but finally I don't understand... > You have written: > ----> the device requires XON/XOFF > > I know it from tenths of years, but I have checked once again: > http://en.wikipedia.org/wiki/Software_flow_control > > Flow control is necessary when one of the communication sides can't receive > data because of somewhat... > So if transmission is fast and short, and machines are fast, XON/XOFF > signals NEVER occurs. > > Execptions....? > ... exception I see now as possible one is the initalisation of the > transmission, but in this case YOU should try to send XON. > > Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 08:29:08 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:29:08 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <20100915140832.GF7681@elberon.bln.de.ingenico.com> References: <20100915140832.GF7681@elberon.bln.de.ingenico.com> Message-ID: yes it could but that call also traces operation on files etc. last time i tried the output was so bloated that i gave up but i should try again 2010/9/15 Steffen DETTMER > * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > > As i said under linux i do not have a powerful tool like portmon on > > windows (funny because usually is the other way round) > > The read and write is pretty simple > > could `strace -e open,read,write -p ' help maybe? > > oki, > > Steffen > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:32:12 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:32:12 +0200 Subject: [Rxtx] JNA In-Reply-To: References: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <20100915143212.GH7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 15:55 +0200: > Additionally I am using a lot of USB dongles simultaneously > (about 20, up to 4 in one of applications) and there is no way > to remember which COM number has THIS dongle on laptop or on > desktop or in another USB socket... The same with CAN reader... > > And therefore I am very happy when I see available ports only - > the highest number of the COM which I have used in last weeks > was COM249 :). Have you used such COM port number? :) Yes, similar things happen with some USB terminals that have to reboot several time in a kind of loop for some test cases, but on linux the used device names were much more cryptic :-) Also, it even seems you can crash many PCs or their USB subsystems by pluging/unplugging and/or booting/rebooting and/or `USB-re-negiotiating' things simultanously/quickly/often enough... > I have had to clean registry quite often... > I think that now you understand my point of view on hardcoded > COM ports list :))) Yes, I do and of course you are right with your statements. I just wanted to point out that in case everything fails and the list that usually shows the available ports would be completely empty, because both methods of enumerating them failed, it could be useful in some circumstances to have then at least a list of COM1..COM10 instead of an empty one, especially in a `must not happen' case, but the application has a way to notice this of course (and I would never expect a library to perform such fallbacks unless explicitely documented - troubleshoting this would be a nightmare...). In other words, it could be considered a way to fail softer and/or to limit damage in some special cases, but as also told in this thread this should be configurable. Since the default should probably be `disabled', the whole feature is even a bit more doubtful, because in case the application is aware of this situation, it could implement a fallback (such as a text input dialog) anyway - this specific implementation surely would suit better to the applications situation. I just wanted to point out that there are situations in which a `better than nothing' fallback is suited, but I agree that this one may not being one of them (however, no need to call it with words, but the OP was even worse... but now again lets all be friends!). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:40:31 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:40:31 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: ----- Original Message ----- From: "Kustaa Nyholm" To: Sent: Wednesday, September 15, 2010 4:04 PM Subject: Re: [Rxtx] XON XOFF under linux > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent ^^^^^^ HERE may be the problem as well: "SHOULD BE" but in many cases ISN'T. Mariusz From adrian.crum at yahoo.com Wed Sep 15 08:49:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 15 Sep 2010 07:49:02 -0700 (PDT) Subject: [Rxtx] Port Discovery/Enumeration (Was: JNA) In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <582091.78813.qm@web63105.mail.re1.yahoo.com> --- On Wed, 9/15/10, Steffen DETTMER wrote: > Indeed the application shall have a way to notice the > problem > that should never occure. Also, a better fallback probably > would > be the classic port enumeration code (althrough I also > dislike if > this `probing' modifies control lines of those ports; but > I'm not > neutral here anyway, because I dislike such `browsing' > stuff and > would prefere to be able to enter the port name to use, as > used > to be on classic unices and even if the serial port happens > to be > a terminal or even a FIFO, almost everything works). Let's not forget that you can specify ports in the properties file. Automatic port discovery and enumeration is not reliable and it has bad side-effects. Improving the port discovery/enumeration code is a worthwhile goal, but in the end, a user can always specify the ports they want to use in the properties file. To me, that seems like a universally acceptable fallback method. -Adrian From hybris0 at gmail.com Wed Sep 15 08:50:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:50:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: ok guys.... now i am pissed off i developed with this thing about 4 days......compiling on linux and hell testing in windows because of this problem i managed to finish my work and happily thrown it in his box for future use under, fortunately, windows you gave me some hints, you gave me some things to think about so i take the whole stuff out of his box again, reattach all those nice connections it has and what happens it all works without changing a line of code sometimes things like this happen to me and i really do not have answers it's running now smoothly... i can't believe all the time i spent in trying to figure out what was wrong and probably i'll never know :( thanks anyway 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:18:31 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:18:31 -0400 Subject: [Rxtx] Linux build problem Message-ID: Hi I was wondering if anyone could shed some light on why I'm having the following build problem on Linux. I usually build on windows so this is a bit of a departure for me. I'm trying to build 2.2pre2 (with a few patches) but it doesn't appear like the patches are at fault here. I had a quick look through the *.in files but nothing obvious came to light. Any help would be appreciated. John Coffey $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fPIC checking if gfortran PIC flag -fPIC works... yes checking if gfortran supports -c -o file.o... yes checking whether the gfortran linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking for xcode-select... no checking java.home /usr/java/jdk1.6.0_21/jre adjusted java.home is /usr/java/jdk1.6.0_21 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.6.0_21 checking os.version 2.6.27.25-170.2.72.fc10.i686 configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:11:59] $ make /usr/java/jdk1.6.0_21/bin/javac -classpath .:/home/john/main/javacode/rxtx-devel:/home/john/main/javacode/rxtx-devel/src: -d /home/john/main/javacode/rxtx-devel/ -O -source 1.3 -target 1.3 /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortEnumerator.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortIdentifier.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortOwnershipListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Configure.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2C.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/LPRPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/NoSuchPortException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortAlreadyClosedException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortInUseException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Raw.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485Port.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXCommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXVersion.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnsupportedCommOperationException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnSupportedLoggerException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Zystem.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:138: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String IOException ex = new IOException( String.format( "Port is in use: %s ", e.currentOwner ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:164: cannot find symbol symbol : method format(java.lang.String,java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "RXTX: java %s, native %s", gnu.io.RXTXVersion.getVersion(), gnu.io.RXTXVersion.nativeGetVersion() ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:168: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "Connecting to serial port (%s)..", serialPortName ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:186: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.err.println( String.format( "IO error: %s", e.getMessage() ) ); ^ 4 errors make: *** [/home/john/main/javacode/rxtx-devel/gnu/io/CommDriver.class] Error 1 [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:12:37] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hontvari at flyordie.com Wed Sep 15 16:28:42 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Thu, 16 Sep 2010 00:28:42 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C903D25.5030301@flyordie.com> References: <4C903D25.5030301@flyordie.com> Message-ID: <4C91489A.4080304@flyordie.com> I have found a way to make it work. If the code changes flow control from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it immediately receive both the command responses and the data sent by the remote modem. It is still unclear why setting the flow control makes any difference, considering that the same procedure works in the terminal even if the terminal is set to "no flow control" or XON/XOFF flow control. On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > I want to start a data connection through a mobile phone, acting as a > modem, using AT commands. It does work in a terminal as expected. > > There is a strange behavior when I do the same thing through RXTX. The > modem should respond to the dial (ATD...) command with a CONNECT ... > message, after it successfully connected to the remote modem. It does > respond. But my code receive this message and any data the remote > modem sends only after the data transfer is completed and the modems > disconnects or after the modem temporarily goes into command state > during the session. > > There is a log below and I attached the test class which produced it. > > For the record: The phone is Siemens C55 connected through an > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > 377 Flow control: 0 > 1379 Event: Output buffer is empty (false->true) > 1380 Sent: atd+36304696729\r > 1381 Event: Output buffer is empty (false->true) > 1428 Event: Data available (false->true) > 1528 Read: atd+36304696729\r > 20758 Event: Carrier detect (false->true) > 22800 Event: Output buffer is empty (false->true) > 22800 Sent: Hello World!\r\n > 22801 Event: Output buffer is empty (false->true) > 22801 Sent: Lets go chat!\r\n > 22805 Event: Output buffer is empty (false->true) > 32802 Event: Output buffer is empty (false->true) > 32802 Sent: +++ > 32803 Event: Output buffer is empty (false->true) > 33808 Event: Data available (false->true) > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > \r\r\nOK\r\n > 35803 Event: Output buffer is empty (false->true) > 35803 Sent: ath\r > 35805 Event: Output buffer is empty (false->true) > 35860 Event: Data available (false->true) > 35962 Read: ath\r > 36266 Event: Data available (false->true) > 36367 Read: \r\nOK\r\n > 36368 Event: Carrier detect (true->false) > 37803 The End > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:50:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:50:26 -0400 Subject: [Rxtx] Linux build problem Message-ID: Fixed, sorry my bad! I had an extraneous file in my build which the auto-conf script was picking up. It's compiling now. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Sep 15 18:33:38 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 16 Sep 2010 01:33:38 +0100 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C91489A.4080304@flyordie.com> References: <4C903D25.5030301@flyordie.com> <4C91489A.4080304@flyordie.com> Message-ID: <20100916013338.2a7f78c7@g0poy-server.site> It is possible that by setting the hardware flow control it may be setting the correct conditions for the data flow to start. My first thought would be to hang a breakout box on the cable and see what (if anything) changes It would not be the first time I've found that a device set to Xon-Xoff or even no flow control needing to see the correct conditions on the hardware control lines before it would start to work correctly. windows Hyperterm is one such troublemaker, sometimes and I've never worked out what causes it, sometimes it just stops working or will not start. The only way to wake it up is to fiddle with the control lines, and eventually it starts. One company I worked for gave up recommending it as a terminal, due to the number of help calls we got, and we switched to Tera Term, and the problems went away. Andy On Thu, 16 Sep 2010 00:28:42 +0200 Hontv?ri J?zsef Levente wrote: > I have found a way to make it work. If the code changes flow control > from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it > immediately receive both the command responses and the data sent by the > remote modem. > > It is still unclear why setting the flow control makes any difference, > considering that the same procedure works in the terminal even if the > terminal is set to "no flow control" or XON/XOFF flow control. > > > On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > > I want to start a data connection through a mobile phone, acting as a > > modem, using AT commands. It does work in a terminal as expected. > > > > There is a strange behavior when I do the same thing through RXTX. The > > modem should respond to the dial (ATD...) command with a CONNECT ... > > message, after it successfully connected to the remote modem. It does > > respond. But my code receive this message and any data the remote > > modem sends only after the data transfer is completed and the modems > > disconnects or after the modem temporarily goes into command state > > during the session. > > > > There is a log below and I attached the test class which produced it. > > > > For the record: The phone is Siemens C55 connected through an > > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > > > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > 377 Flow control: 0 > > 1379 Event: Output buffer is empty (false->true) > > 1380 Sent: atd+36304696729\r > > 1381 Event: Output buffer is empty (false->true) > > 1428 Event: Data available (false->true) > > 1528 Read: atd+36304696729\r > > 20758 Event: Carrier detect (false->true) > > 22800 Event: Output buffer is empty (false->true) > > 22800 Sent: Hello World!\r\n > > 22801 Event: Output buffer is empty (false->true) > > 22801 Sent: Lets go chat!\r\n > > 22805 Event: Output buffer is empty (false->true) > > 32802 Event: Output buffer is empty (false->true) > > 32802 Sent: +++ > > 32803 Event: Output buffer is empty (false->true) > > 33808 Event: Data available (false->true) > > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > > \r\r\nOK\r\n > > 35803 Event: Output buffer is empty (false->true) > > 35803 Sent: ath\r > > 35805 Event: Output buffer is empty (false->true) > > 35860 Event: Data available (false->true) > > 35962 Read: ath\r > > 36266 Event: Data available (false->true) > > 36367 Read: \r\nOK\r\n > > 36368 Event: Carrier detect (true->false) > > 37803 The End > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Sep 17 06:18:58 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 14:18:58 +0200 Subject: [Rxtx] well known disconnect and crash problem Message-ID: <201009171418.58406.lucio@sulweb.org> Hello *, I'd need a version of rxtx without the "crash on disconnect" problem. I've read a few posts claiming a java-only solution, while some other offer a patch, e.g. the one attached to bug#144. What's the best way to go? Has 2.2pre2 the same problem? @Adrian Crum: do you think the rewrite is stable enough for simple reading from a single port on Linux and Windows in a production app? Thanks in advance Lucio. From mariusz.dec at gmail.com Fri Sep 17 08:14:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Fri, 17 Sep 2010 16:14:29 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> Message-ID: ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 2:18 PM Subject: [Rxtx] well known disconnect and crash problem > Hello *, > > I'd need a version of rxtx without the "crash on disconnect" problem. I've At first read carefully thread "RXTX - USB disconnecting safe and fast data transfer to app" And note that there is written about RXTX and USB disconnect. There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works in many cases. Mariusz From lucio at sulweb.org Fri Sep 17 09:07:11 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 17:07:11 +0200 Subject: [Rxtx] well known disconnect and crash problem In-Reply-To: References: <201009171418.58406.lucio@sulweb.org> Message-ID: <201009171707.11477.lucio@sulweb.org> In data venerd? 17 settembre 2010 16:14:29, M.Dec-GM ha scritto: > ----- Original Message ----- > At first read carefully thread "RXTX - USB disconnecting safe and fast data > transfer to app" And note that there is written about RXTX and USB > disconnect. Sometimes I feel the general attitude on this list not being very friendly, but I can't bet, 'cause it may very well be my poor english knowledge... never mind, could you please drop me a pointer to that thread? I subscribed to this list only 2 months ago and I have no idea where to start looking for it in the list archives. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Thanks again, Lucio. From mariusz.dec at gmail.com Fri Sep 17 11:32:32 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 17 Sep 2010 19:32:32 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> <201009171707.11477.lucio@sulweb.org> Message-ID: <986039CEE912457F87F43A281ED43768@mdam2> ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 5:07 PM There are main http://mailman.qbang.org/pipermail/rxtx/2010-September/7047577.html and next one with small improvement. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Almost 100 percent probability: - YES. But you have to good understand comments inside examples to adapt it for your code!!! In some places it looks and in fact is a bit complicated but ... works. Mariusz From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:38:31 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:38:31 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: it sends 5 bytes, \r\n are printed and the output goes on the next line as a side effect (sorry if i did not point it out). anyway the code: sh.write("1TS\r\n"); where sh.write does this: public void write(String s) throws IOException { debug(String.format(">>> %s", s)); outputStream.write(s.getBytes()); } outputStream is a bare OutputStream obtained from the serial port on the reading side i use a buffered reader to read lines, the doc states that a line is ended by \n or \r\n so it should be platform indepentent public String readLine() throws IOException { String s = reader.readLine(); debug(String.format("<<< %s", s)); return s; } reader is a BufferedReader built around the serialport input stream reader = new BufferedReader(new InputStreamReader(is)); 2010/9/15 Kustaa Nyholm > > > > > The output i reported is written by my java application when it sends and > when > > it receive. > > I still do not quite understand what happens at the code level. > > Your program outputs: > > > On linux instead i have this: > > > > 2010-09-07 12.16.40: >>> 1TS > > timeout > > 2010-09-07 12.16.42: >>> 1TS > > 2010-09-07 12.16.42: <<< 3 > > 2010-09-07 12.16.43: >>> 1TS > > timeout > > So your code sends '1TS' and then get timeout? On write? > > Why it only send three bytes, or how do you know it only sends three bytes, > what I'm trying to say is that if I had programmed this the code would look > something like: > > outstream.write(bytestosend,0,bytestosend.length); > > and thus I would not know that I've only sent three bytes. So evidently > your code is different and that's why I suggested that it might be > helpful to actually see the code. > > Or am I missing something here? > > 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 andy at g0poy.com Wed Sep 15 07:40:16 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 15 Sep 2010 14:40:16 +0100 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915144016.2630de90@g0poy-server.site> Would strace help you? I've seen some references to this particularly with the -e read=set and -e write=set options. Trouble is, that I don't fully understand strace :-( Andy On Wed, 15 Sep 2010 14:42:23 +0200 Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm > > > > > >> The protocol used is an ascii protocol with CR/LF terminator for > > messages. > > > > In Windows CR/LF is often used in line termination and this convention > > is buried in lots of code ... whereas in *nix world LF only is used. > > > > So could this be related to your issue? > > > > It could be helpful if you described how you grabbed the dump > > of what is happening, now it is unclear weather you have > > observed the communication on the PC side, or device side, or > > on the actual serial communication line. > > > > Also it might be useful to show the code that actually read/write > > the port, not just the port initialization. > > > > br Kusti > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From hybris0 at gmail.com Wed Sep 15 07:40:04 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:04 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: i was not able to get it work....it does not capture anything.... 2010/9/15 George H > On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > > The output i reported is written by my java application when it sends and > > when it receive. > > As i said under linux i do not have a powerful tool like portmon on > windows > > (funny because usually is the other way round) > > > > Will this work ? http://www.rolf-schroedter.de/moni/ > > -- > George H > george.dma at gmail.com > > > The read and write is pretty simple and is done using the streams coming > > from the serial ports and yes, after each write i do a flush, even if i > do > > not use buffered streams because i saw it must be done otherwise stuff > > remains on the pc side. > > > > > > 2010/9/15 Kustaa Nyholm > >> > >> >> The protocol used is an ascii protocol with CR/LF terminator for > >> >> messages. > >> > >> In Windows CR/LF is often used in line termination and this convention > >> is buried in lots of code ... whereas in *nix world LF only is used. > >> > >> So could this be related to your issue? > >> > >> It could be helpful if you described how you grabbed the dump > >> of what is happening, now it is unclear weather you have > >> observed the communication on the PC side, or device side, or > >> on the actual serial communication line. > >> > >> Also it might be useful to show the code that actually read/write > >> the port, not just the port initialization. > >> > >> br Kusti > >> > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:40:59 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:59 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <1CD57CB0C6974785BFAB43E383D60295@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: the device requires XON/XOFF i don't get the hint about Netbeans that, btw i am using. 2010/9/15 M.Dec-GM > And what about this problem - how it works WITHOUT XON/XOFF? > Assuming (with overhead) 12 bits per byte and 12 bytes, your > transmission duration is 2.5 ms. > If you said that system is enough fast, should find 2,5 ms in each second > to serve this packet :) > > BTW: Netbeans for Linux is very easy to install and use.... no differences > :) > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 2:48 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > I am working on a PC, no PDAs....i exclude the fact that linux is too slow. > I already used RXTX under linux with no problem at all. > Also, since i was not unable to debug the application in Linux i debugged > it in Windows running in a virtual machine under the same Linux. > > Even if XON/XOFF is so simple i keep its implementations as a last resort. > Fortunately i develop on Linux but, in this case, deploy on windows so i > can workaround it this way.... debugging is a bit tedious done this way but > the protocol is sufficiently simple to not require too much debugging. In > fact i am done with it. > > I already tried to link to the RXTX sources but it seems that the flow > control stuff is done in the C part. > > 2010/9/15 M.Dec-GMail > >> Ok, >> Have you a Java source of the application? >> >> If yes, you may do a trick, which I did when I was fighting with close() >> in Linux :) >> I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to >> the application folder. >> >> !!! >> You have to remove EACH copy of the RXTX.jar from the system, and stay >> with application sources with RXTX inside. >> !!! >> >> In this case you will have very deep access to RXTX sources >> Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF >> codes. >> >> As a final/least solution is own XON/XOFF protocoll - very simple - >> believe me :) >> I think that it will be faster to write than looking for Linux >> codes/problems. >> >> OR >> >> maybe there is a Java software mistake in Serial service which is better >> visible/more critical in Linux? >> >> Switch XON/XOFF at all and try how it works. >> You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, >> assumming 10 bytes of data + CRLF. >> >> OR >> Another idea - try to send device's XON after first query... >> >> 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - >> what the computer is this - PC or small PDA, ARM? >> >> Mariusz >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 1:56 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> The protocol is not binary and the device works only that way. >> >> I'll do some of the checks you mentioned but it seems fair to me expecting >> rxtx to behave the same way on windows and linux. >> >> I recognize that it can also be a buffer problem, or a XON/XOFF value >> problem....unfortunately linux does not offer any decent tool for sniffing >> the serial at OS level as far as i know. >> >> 2010/9/15 M.Dec-GM >> >>> Hi, >>> Using XON-XOFF software handshake protocol has a some limitations - bytes >>> for XON and for XOFF are not usable, so you shouldn't transfer binary data >>> through channel. >>> This is why I am not using this protocol at all. >>> But it isn't answer yet :) >>> >>> Maybe this helps: >>> 1. Please check if codes for XON/XOFF are identical in host and client. >>> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >>> be defined by user and I did a mistake - I have forgotten to switch >>> automatic XON/XOFF in tool, but both codes were 0x00 by default... >>> You know what it means when binary data were transmitted... crazy :). >>> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >>> only... >>> 4. Looking on the problem from another side - think if XON/XOFF is >>> necessary for now, maybe bigger buffer will be enough, or simply write >>> yourself the >>> service for XON/XOFF - this very easy, and you may use my examples for >>> this job. >>> There is enough to check XOFF in SerialReader and stop writing until XON >>> will come... >>> >>> Good luck :) >>> Mariusz >>> >>> >>> >>> >>> ----- Original Message ----- >>> *From:* Hybris >>> *To:* rxtx at qbang.org >>> *Sent:* Wednesday, September 15, 2010 12:46 PM >>> *Subject:* Re: [Rxtx] XON XOFF under linux >>> >>> Nobody can help on this? >>> >>> 2010/9/7 Hybris >>> >>>> Hi, >>>> i have a problem under Linux. >>>> I often used the library (last stable release 2.1) without any problem >>>> in this environment. >>>> >>>> Without any other clues at the moment i am blaming the fact i am >>>> talking a device that requires XON/XOFF as flow control method. A >>>> method i never used before. >>>> >>>> Under windows i have no problems, under Linux commands are received by >>>> the device but i do not get replies or i get truncated replies (log >>>> follows) >>>> >>>> I am using the seial port builtin the motherboard, no usb converters. >>>> >>>> I initialize the port this way: >>>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>>> serialPort.setInputBufferSize(256); >>>> serialPort.setOutputBufferSize(256); >>>> serialPort.enableReceiveTimeout(1000); >>>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>>> >>>> The protocol used is an ascii protocol with CR/LF terminator for >>>> messages. >>>> >>>> The output i get on windows for a cycle of request/response (one per >>>> second) is this (>>> from PC to the device, <<< from device to PC): >>>> >>>> 2010-09-07 12.18.07: <<< 1TS000033 >>>> 2010-09-07 12.18.08: >>> 1TS >>>> 2010-09-07 12.18.08: <<< 1TS000033 >>>> 2010-09-07 12.18.09: >>> 1TS >>>> 2010-09-07 12.18.09: <<< 1TS000033 >>>> 2010-09-07 12.18.10: >>> 1TS >>>> 2010-09-07 12.18.10: <<< 1TS000033 >>>> 2010-09-07 12.18.11: >>> 1TS >>>> 2010-09-07 12.18.11: <<< 1TS000033 >>>> >>>> On linux instead i have this: >>>> >>>> 2010-09-07 12.16.40: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.42: >>> 1TS >>>> 2010-09-07 12.16.42: <<< 3 >>>> 2010-09-07 12.16.43: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.45: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.47: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.49: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.51: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.53: >>> 1TS >>>> 2010-09-07 12.16.53: <<< 3 >>>> 2010-09-07 12.16.54: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.56: >>> 1TS >>>> 2010-09-07 12.16.56: <<< 1TS000033 >>>> 2010-09-07 12.16.57: >>> 1TS >>>> 2010-09-07 12.16.58: <<< 3 >>>> 2010-09-07 12.16.59: >>> 1TS >>>> timeout >>>> 2010-09-07 12.17.01: >>> 1TS >>>> timeout >>>> >>>> Any ideas? >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 15 07:55:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:55:58 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com><95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: Hi Steffen, > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports Currently I am using Windows application (USB CAN reader for my car) where is the default list of the ports (COM64 is the highest one). Additionally I am using a lot of USB dongles simultaneously (about 20, up to 4 in one of applications) and there is no way to remember which COM number has THIS dongle on laptop or on desktop or in another USB socket... The same with CAN reader... And therefore I am very happy when I see available ports only - the highest number of the COM which I have used in last weeks was COM249 :). Have you used such COM port number? :) I have had to clean registry quite often... I think that now you understand my point of view on hardcoded COM ports list :))) Regards Mariusz From tjarvi at qbang.org Wed Sep 15 07:36:32 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Sep 2010 07:36:32 -0600 (MDT) Subject: [Rxtx] JNA In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: On Wed, 15 Sep 2010, Steffen DETTMER wrote: > * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: >> Hi all, >> So - this:part looks crazy: >>> // In case of errors, list COM1 through COM9 - it is better than nothing. >>> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for > > maybe better: `a doubtful'? > >> list [...]: "it is better than nothing", >> if such list gives no useful information... >> >> Please try to connect to the port from this list.... "Better >> than nothing" is to write - No ports, List Error or something >> like that... > > Indeed the application shall have a way to notice the problem > that should never occure. Also, a better fallback probably would > be the classic port enumeration code (althrough I also dislike if > this `probing' modifies control lines of those ports; but I'm not > neutral here anyway, because I dislike such `browsing' stuff and > would prefere to be able to enter the port name to use, as used > to be on classic unices and even if the serial port happens to be > a terminal or even a FIFO, almost everything works). > > Also, it might be insufficient to present the list of currently > available serial ports, for example in a configuration dialog I > may wish to configure ports which currently are not connected. > AFAIK, this for example is simply not possible with windows > hardware device manager, because in case the USB device is not > plugged you have it in no list where you could click it; bad... > So I think a good application should allow users to specify ports > directly anyway and no such fallback would be required. > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports > usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, > so such a fallback could help the majority of users where both > registry lookup and `port probing' fail. Of course it is hard to > tell what will happen on systems of the windows users where > registry lookups fail, probably nothing will work anyway, but who > knows :) > I'd just add that laptops are the most common computer people use today and very few actually have serial ports out of the box. No ports available is a useful answer. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Sep 15 08:04:50 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 17:04:50 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > it sends 5 bytes, \r\n are printed and the output goes on the next line as a > side effect (sorry if i did not point it out). > > anyway the code: > > sh.write("1TS\r\n"); > > where sh.write does this: > > public void write(String s) throws IOException { > ??????? debug(String.format(">>> %s", s)); > ??????? outputStream.write(s.getBytes()); > } Java doc for String.getBytes() says: "Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array." Could it be that the default charset on your Linux system is different from Windows and this messes things up? > > outputStream is a bare OutputStream obtained from the serial port > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent > > public String readLine() throws IOException { > ??????? String s = reader.readLine(); > ??????? debug(String.format("<<< %s", s)); > ??????? return s; > ??? } > > reader is a BufferedReader built around the serialport input stream > reader = new BufferedReader(new InputStreamReader(is)); > > Nothing strikes me as suspicious above. But I still do not understand this, you said (for Windows): >>> 2010-09-07 12.1807: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 ' where does that '000033 come and why it is different in the Linux case? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 08:08:32 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:08:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915140832.GF7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > As i said under linux i do not have a powerful tool like portmon on > windows (funny because usually is the other way round) > The read and write is pretty simple could `strace -e open,read,write -p ' help maybe? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:12:49 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:12:49 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2><1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <05754F9E14B746D1B81F2827F7E738F6@mdam2> Sorry, but finally I don't understand... You have written: ----> the device requires XON/XOFF I know it from tenths of years, but I have checked once again: http://en.wikipedia.org/wiki/Software_flow_control Flow control is necessary when one of the communication sides can't receive data because of somewhat... So if transmission is fast and short, and machines are fast, XON/XOFF signals NEVER occurs. Execptions....? ... exception I see now as possible one is the initalisation of the transmission, but in this case YOU should try to send XON. Mariusz From hybris0 at gmail.com Wed Sep 15 08:16:48 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:16:48 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: 2010/9/15 Kustaa Nyholm > > Could it be that the default charset on your Linux system is different from > Windows and this messes things up? > > yes it could but since i use only ASCII it could not. Anyway i just tested it and the list of bytes generated is correct so the problem is not there. > But I still do not understand this, you said (for Windows): [...] > > where does that '000033 come and why it is different in the Linux case? > > 1TS000033 is the reply from the device at the command 1TS the linux case is different imho because the flow control is messing things up....but i can't prove it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:19:37 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:19:37 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <20100915141937.GG7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 15:40 +0200: > And what about this problem - how it works WITHOUT XON/XOFF? I'm not sure if I understand the question correctly, but in case it helps: If you are able to always receive full speed (e.g. because on a fine PC) and you write slowing (some Thread.Sleep(50) per each few bytes or so), you should never need to send XOFF and the device should never need to do so; maybe you need to send XON once at the begin (if device starts in XOFF) but everything else should work `transparently' in this special case (i.e. PC is receiving fast but sending slowly). You told you're working on linux; here shell console windows (xterm etc) are XON/XOFF (CTRL-Q / CTRL-S), so you know how it works: as long as you don't press CTRL-S, text scrolls through. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From hybris0 at gmail.com Wed Sep 15 08:26:58 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:26:58 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <05754F9E14B746D1B81F2827F7E738F6@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> <05754F9E14B746D1B81F2827F7E738F6@mdam2> Message-ID: i understand your point and i admit ignorance on how XON/XOFF worked.... i have to assume some things as blackboxes sometimes otherwise i'll go crazy i'll investigate further 2010/9/15 M.Dec-GM > Sorry, but finally I don't understand... > You have written: > ----> the device requires XON/XOFF > > I know it from tenths of years, but I have checked once again: > http://en.wikipedia.org/wiki/Software_flow_control > > Flow control is necessary when one of the communication sides can't receive > data because of somewhat... > So if transmission is fast and short, and machines are fast, XON/XOFF > signals NEVER occurs. > > Execptions....? > ... exception I see now as possible one is the initalisation of the > transmission, but in this case YOU should try to send XON. > > Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 08:29:08 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:29:08 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <20100915140832.GF7681@elberon.bln.de.ingenico.com> References: <20100915140832.GF7681@elberon.bln.de.ingenico.com> Message-ID: yes it could but that call also traces operation on files etc. last time i tried the output was so bloated that i gave up but i should try again 2010/9/15 Steffen DETTMER > * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > > As i said under linux i do not have a powerful tool like portmon on > > windows (funny because usually is the other way round) > > The read and write is pretty simple > > could `strace -e open,read,write -p ' help maybe? > > oki, > > Steffen > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:32:12 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:32:12 +0200 Subject: [Rxtx] JNA In-Reply-To: References: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <20100915143212.GH7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 15:55 +0200: > Additionally I am using a lot of USB dongles simultaneously > (about 20, up to 4 in one of applications) and there is no way > to remember which COM number has THIS dongle on laptop or on > desktop or in another USB socket... The same with CAN reader... > > And therefore I am very happy when I see available ports only - > the highest number of the COM which I have used in last weeks > was COM249 :). Have you used such COM port number? :) Yes, similar things happen with some USB terminals that have to reboot several time in a kind of loop for some test cases, but on linux the used device names were much more cryptic :-) Also, it even seems you can crash many PCs or their USB subsystems by pluging/unplugging and/or booting/rebooting and/or `USB-re-negiotiating' things simultanously/quickly/often enough... > I have had to clean registry quite often... > I think that now you understand my point of view on hardcoded > COM ports list :))) Yes, I do and of course you are right with your statements. I just wanted to point out that in case everything fails and the list that usually shows the available ports would be completely empty, because both methods of enumerating them failed, it could be useful in some circumstances to have then at least a list of COM1..COM10 instead of an empty one, especially in a `must not happen' case, but the application has a way to notice this of course (and I would never expect a library to perform such fallbacks unless explicitely documented - troubleshoting this would be a nightmare...). In other words, it could be considered a way to fail softer and/or to limit damage in some special cases, but as also told in this thread this should be configurable. Since the default should probably be `disabled', the whole feature is even a bit more doubtful, because in case the application is aware of this situation, it could implement a fallback (such as a text input dialog) anyway - this specific implementation surely would suit better to the applications situation. I just wanted to point out that there are situations in which a `better than nothing' fallback is suited, but I agree that this one may not being one of them (however, no need to call it with words, but the OP was even worse... but now again lets all be friends!). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:40:31 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:40:31 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: ----- Original Message ----- From: "Kustaa Nyholm" To: Sent: Wednesday, September 15, 2010 4:04 PM Subject: Re: [Rxtx] XON XOFF under linux > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent ^^^^^^ HERE may be the problem as well: "SHOULD BE" but in many cases ISN'T. Mariusz From adrian.crum at yahoo.com Wed Sep 15 08:49:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 15 Sep 2010 07:49:02 -0700 (PDT) Subject: [Rxtx] Port Discovery/Enumeration (Was: JNA) In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <582091.78813.qm@web63105.mail.re1.yahoo.com> --- On Wed, 9/15/10, Steffen DETTMER wrote: > Indeed the application shall have a way to notice the > problem > that should never occure. Also, a better fallback probably > would > be the classic port enumeration code (althrough I also > dislike if > this `probing' modifies control lines of those ports; but > I'm not > neutral here anyway, because I dislike such `browsing' > stuff and > would prefere to be able to enter the port name to use, as > used > to be on classic unices and even if the serial port happens > to be > a terminal or even a FIFO, almost everything works). Let's not forget that you can specify ports in the properties file. Automatic port discovery and enumeration is not reliable and it has bad side-effects. Improving the port discovery/enumeration code is a worthwhile goal, but in the end, a user can always specify the ports they want to use in the properties file. To me, that seems like a universally acceptable fallback method. -Adrian From hybris0 at gmail.com Wed Sep 15 08:50:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:50:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: ok guys.... now i am pissed off i developed with this thing about 4 days......compiling on linux and hell testing in windows because of this problem i managed to finish my work and happily thrown it in his box for future use under, fortunately, windows you gave me some hints, you gave me some things to think about so i take the whole stuff out of his box again, reattach all those nice connections it has and what happens it all works without changing a line of code sometimes things like this happen to me and i really do not have answers it's running now smoothly... i can't believe all the time i spent in trying to figure out what was wrong and probably i'll never know :( thanks anyway 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:18:31 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:18:31 -0400 Subject: [Rxtx] Linux build problem Message-ID: Hi I was wondering if anyone could shed some light on why I'm having the following build problem on Linux. I usually build on windows so this is a bit of a departure for me. I'm trying to build 2.2pre2 (with a few patches) but it doesn't appear like the patches are at fault here. I had a quick look through the *.in files but nothing obvious came to light. Any help would be appreciated. John Coffey $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fPIC checking if gfortran PIC flag -fPIC works... yes checking if gfortran supports -c -o file.o... yes checking whether the gfortran linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking for xcode-select... no checking java.home /usr/java/jdk1.6.0_21/jre adjusted java.home is /usr/java/jdk1.6.0_21 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.6.0_21 checking os.version 2.6.27.25-170.2.72.fc10.i686 configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:11:59] $ make /usr/java/jdk1.6.0_21/bin/javac -classpath .:/home/john/main/javacode/rxtx-devel:/home/john/main/javacode/rxtx-devel/src: -d /home/john/main/javacode/rxtx-devel/ -O -source 1.3 -target 1.3 /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortEnumerator.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortIdentifier.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortOwnershipListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Configure.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2C.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/LPRPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/NoSuchPortException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortAlreadyClosedException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortInUseException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Raw.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485Port.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXCommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXVersion.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnsupportedCommOperationException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnSupportedLoggerException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Zystem.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:138: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String IOException ex = new IOException( String.format( "Port is in use: %s ", e.currentOwner ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:164: cannot find symbol symbol : method format(java.lang.String,java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "RXTX: java %s, native %s", gnu.io.RXTXVersion.getVersion(), gnu.io.RXTXVersion.nativeGetVersion() ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:168: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "Connecting to serial port (%s)..", serialPortName ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:186: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.err.println( String.format( "IO error: %s", e.getMessage() ) ); ^ 4 errors make: *** [/home/john/main/javacode/rxtx-devel/gnu/io/CommDriver.class] Error 1 [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:12:37] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hontvari at flyordie.com Wed Sep 15 16:28:42 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Thu, 16 Sep 2010 00:28:42 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C903D25.5030301@flyordie.com> References: <4C903D25.5030301@flyordie.com> Message-ID: <4C91489A.4080304@flyordie.com> I have found a way to make it work. If the code changes flow control from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it immediately receive both the command responses and the data sent by the remote modem. It is still unclear why setting the flow control makes any difference, considering that the same procedure works in the terminal even if the terminal is set to "no flow control" or XON/XOFF flow control. On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > I want to start a data connection through a mobile phone, acting as a > modem, using AT commands. It does work in a terminal as expected. > > There is a strange behavior when I do the same thing through RXTX. The > modem should respond to the dial (ATD...) command with a CONNECT ... > message, after it successfully connected to the remote modem. It does > respond. But my code receive this message and any data the remote > modem sends only after the data transfer is completed and the modems > disconnects or after the modem temporarily goes into command state > during the session. > > There is a log below and I attached the test class which produced it. > > For the record: The phone is Siemens C55 connected through an > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > 377 Flow control: 0 > 1379 Event: Output buffer is empty (false->true) > 1380 Sent: atd+36304696729\r > 1381 Event: Output buffer is empty (false->true) > 1428 Event: Data available (false->true) > 1528 Read: atd+36304696729\r > 20758 Event: Carrier detect (false->true) > 22800 Event: Output buffer is empty (false->true) > 22800 Sent: Hello World!\r\n > 22801 Event: Output buffer is empty (false->true) > 22801 Sent: Lets go chat!\r\n > 22805 Event: Output buffer is empty (false->true) > 32802 Event: Output buffer is empty (false->true) > 32802 Sent: +++ > 32803 Event: Output buffer is empty (false->true) > 33808 Event: Data available (false->true) > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > \r\r\nOK\r\n > 35803 Event: Output buffer is empty (false->true) > 35803 Sent: ath\r > 35805 Event: Output buffer is empty (false->true) > 35860 Event: Data available (false->true) > 35962 Read: ath\r > 36266 Event: Data available (false->true) > 36367 Read: \r\nOK\r\n > 36368 Event: Carrier detect (true->false) > 37803 The End > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:50:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:50:26 -0400 Subject: [Rxtx] Linux build problem Message-ID: Fixed, sorry my bad! I had an extraneous file in my build which the auto-conf script was picking up. It's compiling now. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Sep 15 18:33:38 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 16 Sep 2010 01:33:38 +0100 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C91489A.4080304@flyordie.com> References: <4C903D25.5030301@flyordie.com> <4C91489A.4080304@flyordie.com> Message-ID: <20100916013338.2a7f78c7@g0poy-server.site> It is possible that by setting the hardware flow control it may be setting the correct conditions for the data flow to start. My first thought would be to hang a breakout box on the cable and see what (if anything) changes It would not be the first time I've found that a device set to Xon-Xoff or even no flow control needing to see the correct conditions on the hardware control lines before it would start to work correctly. windows Hyperterm is one such troublemaker, sometimes and I've never worked out what causes it, sometimes it just stops working or will not start. The only way to wake it up is to fiddle with the control lines, and eventually it starts. One company I worked for gave up recommending it as a terminal, due to the number of help calls we got, and we switched to Tera Term, and the problems went away. Andy On Thu, 16 Sep 2010 00:28:42 +0200 Hontv?ri J?zsef Levente wrote: > I have found a way to make it work. If the code changes flow control > from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it > immediately receive both the command responses and the data sent by the > remote modem. > > It is still unclear why setting the flow control makes any difference, > considering that the same procedure works in the terminal even if the > terminal is set to "no flow control" or XON/XOFF flow control. > > > On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > > I want to start a data connection through a mobile phone, acting as a > > modem, using AT commands. It does work in a terminal as expected. > > > > There is a strange behavior when I do the same thing through RXTX. The > > modem should respond to the dial (ATD...) command with a CONNECT ... > > message, after it successfully connected to the remote modem. It does > > respond. But my code receive this message and any data the remote > > modem sends only after the data transfer is completed and the modems > > disconnects or after the modem temporarily goes into command state > > during the session. > > > > There is a log below and I attached the test class which produced it. > > > > For the record: The phone is Siemens C55 connected through an > > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > > > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > 377 Flow control: 0 > > 1379 Event: Output buffer is empty (false->true) > > 1380 Sent: atd+36304696729\r > > 1381 Event: Output buffer is empty (false->true) > > 1428 Event: Data available (false->true) > > 1528 Read: atd+36304696729\r > > 20758 Event: Carrier detect (false->true) > > 22800 Event: Output buffer is empty (false->true) > > 22800 Sent: Hello World!\r\n > > 22801 Event: Output buffer is empty (false->true) > > 22801 Sent: Lets go chat!\r\n > > 22805 Event: Output buffer is empty (false->true) > > 32802 Event: Output buffer is empty (false->true) > > 32802 Sent: +++ > > 32803 Event: Output buffer is empty (false->true) > > 33808 Event: Data available (false->true) > > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > > \r\r\nOK\r\n > > 35803 Event: Output buffer is empty (false->true) > > 35803 Sent: ath\r > > 35805 Event: Output buffer is empty (false->true) > > 35860 Event: Data available (false->true) > > 35962 Read: ath\r > > 36266 Event: Data available (false->true) > > 36367 Read: \r\nOK\r\n > > 36368 Event: Carrier detect (true->false) > > 37803 The End > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Sep 17 06:18:58 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 14:18:58 +0200 Subject: [Rxtx] well known disconnect and crash problem Message-ID: <201009171418.58406.lucio@sulweb.org> Hello *, I'd need a version of rxtx without the "crash on disconnect" problem. I've read a few posts claiming a java-only solution, while some other offer a patch, e.g. the one attached to bug#144. What's the best way to go? Has 2.2pre2 the same problem? @Adrian Crum: do you think the rewrite is stable enough for simple reading from a single port on Linux and Windows in a production app? Thanks in advance Lucio. From mariusz.dec at gmail.com Fri Sep 17 08:14:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Fri, 17 Sep 2010 16:14:29 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> Message-ID: ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 2:18 PM Subject: [Rxtx] well known disconnect and crash problem > Hello *, > > I'd need a version of rxtx without the "crash on disconnect" problem. I've At first read carefully thread "RXTX - USB disconnecting safe and fast data transfer to app" And note that there is written about RXTX and USB disconnect. There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works in many cases. Mariusz From lucio at sulweb.org Fri Sep 17 09:07:11 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 17:07:11 +0200 Subject: [Rxtx] well known disconnect and crash problem In-Reply-To: References: <201009171418.58406.lucio@sulweb.org> Message-ID: <201009171707.11477.lucio@sulweb.org> In data venerd? 17 settembre 2010 16:14:29, M.Dec-GM ha scritto: > ----- Original Message ----- > At first read carefully thread "RXTX - USB disconnecting safe and fast data > transfer to app" And note that there is written about RXTX and USB > disconnect. Sometimes I feel the general attitude on this list not being very friendly, but I can't bet, 'cause it may very well be my poor english knowledge... never mind, could you please drop me a pointer to that thread? I subscribed to this list only 2 months ago and I have no idea where to start looking for it in the list archives. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Thanks again, Lucio. From mariusz.dec at gmail.com Fri Sep 17 11:32:32 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 17 Sep 2010 19:32:32 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> <201009171707.11477.lucio@sulweb.org> Message-ID: <986039CEE912457F87F43A281ED43768@mdam2> ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 5:07 PM There are main http://mailman.qbang.org/pipermail/rxtx/2010-September/7047577.html and next one with small improvement. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Almost 100 percent probability: - YES. But you have to good understand comments inside examples to adapt it for your code!!! In some places it looks and in fact is a bit complicated but ... works. Mariusz From namanvit at gmail.com Tue Sep 21 04:18:01 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 15:48:01 +0530 Subject: [Rxtx] error using nativelib in jnlp Message-ID: Hello, I am trying to make a COM reader in java using jnlp. So I have the files RXTXcomm.jar, rxtxwin32.dll. I have made a jar of my nativedlll -> rxtxSerial.dll.jar so my jnlp looks like: new naman.jain new new Code: I have already signed all the three jars involved here using the same certificate. Now I run it but it shows a error: Use of native libraries require unrestricted acces to the system. JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) at com.sun.javaws.Launcher.downloadResources(Unknown Source) at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) at com.sun.javaws.Launcher.launch(Unknown Source) at com.sun.javaws.Main.launchApp(Unknown Source) at com.sun.javaws.Main.continueInSecureThread(Unknown Source) at com.sun.javaws.Main$1.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could anyone please explain what could be the issue? I tried reading other related posts but could not exactly understand the cause of the problem. Regards Naman From george.dma at gmail.com Tue Sep 21 04:54:00 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 13:54:00 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 1:18 PM, naman jain wrote: > Hello, > > > I am trying to make a COM reader in java using jnlp. > > So I have the files RXTXcomm.jar, rxtxwin32.dll. > I have made a jar of my nativedlll -> rxtxSerial.dll.jar > > so my jnlp looks like: > > > ? ? > ? ? ? ?new > ? ? ? ?naman.jain > ? ? ? ? > ? ? ? ?new > ? ? ? ?new > > ? ? > > > ? ? > > > ? ? > ? ? ? ? > > > ? ? > > ? ? > > > Code: > > > > > > > > I have already signed all the three jars involved here using the same > certificate. > > Now I run it but it shows a error: > > Use of native libraries require unrestricted acces to the system. > JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] > ? at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) > ? at com.sun.javaws.Launcher.downloadResources(Unknown Source) > ? at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) > ? at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) > ? at com.sun.javaws.Launcher.launch(Unknown Source) > ? at com.sun.javaws.Main.launchApp(Unknown Source) > ? at com.sun.javaws.Main.continueInSecureThread(Unknown Source) > ? at com.sun.javaws.Main$1.run(Unknown Source) > ? at java.lang.Thread.run(Unknown Source) > > Could anyone please explain what could be the issue? > I tried reading other related posts but could not exactly understand > the cause of the problem. > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, I have had issues with native dlls and JNLP a long time ago and it is quite tricky to work. As you know programs running from JNLPs are subject to strict security which includes signing the jar file. Now you said you signed the jars so there is only 1 thing left to do. You have to explicitly tell the JNLP that the program needs unrestricted access to the system by defining a tag. Try adding this to your JNLP before the resources section. This gives full access of the jnlp app to the system. To fine tune permissions and access you should look at creating policy files which you can find at http://download.oracle.com/javase/1.4.2/docs/guide/security/permissions.html http://download-llnw.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html Hope this helps. -- George H george.dma at gmail.com From george.dma at gmail.com Tue Sep 21 04:54:00 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 13:54:00 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 1:18 PM, naman jain wrote: > Hello, > > > I am trying to make a COM reader in java using jnlp. > > So I have the files RXTXcomm.jar, rxtxwin32.dll. > I have made a jar of my nativedlll -> rxtxSerial.dll.jar > > so my jnlp looks like: > > > ? ? > ? ? ? ?new > ? ? ? ?naman.jain > ? ? ? ? > ? ? ? ?new > ? ? ? ?new > > ? ? > > > ? ? > > > ? ? > ? ? ? ? > > > ? ? > > ? ? > > > Code: > > > > > > > > I have already signed all the three jars involved here using the same > certificate. > > Now I run it but it shows a error: > > Use of native libraries require unrestricted acces to the system. > JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] > ? at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) > ? at com.sun.javaws.Launcher.downloadResources(Unknown Source) > ? at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) > ? at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) > ? at com.sun.javaws.Launcher.launch(Unknown Source) > ? at com.sun.javaws.Main.launchApp(Unknown Source) > ? at com.sun.javaws.Main.continueInSecureThread(Unknown Source) > ? at com.sun.javaws.Main$1.run(Unknown Source) > ? at java.lang.Thread.run(Unknown Source) > > Could anyone please explain what could be the issue? > I tried reading other related posts but could not exactly understand > the cause of the problem. > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, I have had issues with native dlls and JNLP a long time ago and it is quite tricky to work. As you know programs running from JNLPs are subject to strict security which includes signing the jar file. Now you said you signed the jars so there is only 1 thing left to do. You have to explicitly tell the JNLP that the program needs unrestricted access to the system by defining a tag. Try adding this to your JNLP before the resources section. This gives full access of the jnlp app to the system. To fine tune permissions and access you should look at creating policy files which you can find at http://download.oracle.com/javase/1.4.2/docs/guide/security/permissions.html http://download-llnw.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html Hope this helps. -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 05:22:54 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 16:52:54 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > I have had issues with native dlls and JNLP a long time ago and it is > quite tricky to work. As you know programs running from JNLPs are > subject to strict security which includes signing the jar file. Now > you said you signed the jars so there is only 1 thing left to do. > > You have to explicitly tell the JNLP that the program needs > unrestricted access to the system by defining a tag. Try > adding this to your JNLP before the resources section. > > > ? ? ? > Thanks for that. I put that and that error goes off. Though another ones comes in. I looks like really difficult to get it through :). now i get a error that the Jar resources in the jnlp file are not signed by same certificate. This looks a familiar error, But I have signed all three myself with a same certificate. According to my understanding, The problem should be with lib/RXTXcomm.jar as it is a third party jar that I downloaded. So is it signed by some other certificate beforehand. what do we do in such cases, I saw people writing somewher to make a seperate jnlp for RXTXcomm.jar ? Your comments on that. Regards Naman From george.dma at gmail.com Tue Sep 21 05:33:11 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 14:33:11 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 2:22 PM, naman jain wrote: >> I have had issues with native dlls and JNLP a long time ago and it is >> quite tricky to work. As you know programs running from JNLPs are >> subject to strict security which includes signing the jar file. Now >> you said you signed the jars so there is only 1 thing left to do. >> >> You have to explicitly tell the JNLP that the program needs >> unrestricted access to the system by defining a tag. Try >> adding this to your JNLP before the resources section. >> >> >> ? ? ? >> > > Thanks for that. I put that and that error goes off. Though another > ones comes in. > I looks like really difficult to get it through :). > > now i get a error that the > Jar resources in the jnlp file are not signed by same certificate. > > This looks a familiar error, But I have signed all three myself with a > same certificate. > According to my understanding, The problem should be with > lib/RXTXcomm.jar as it is a third party jar that > I downloaded. So is it signed by some other certificate beforehand. > > what do we do in such cases, I saw people writing somewher to make a > seperate jnlp for > RXTXcomm.jar ? > > Your comments on that. > > Regards > Naman Good to hear that the error went away. Umm yes I have had this error you are talking about. What I have done in that case was sign the jar files with my certificate. Note that where I was working we were distributing java programs via JNLP internally on our WAN so it was nothing anyone outside the company would use. I would even remove other certificates from jar files and replace them with our own, this was a problem I had when I jar file was signed by 2 different people. So try to sign the RXTXcomm.jar and see if that solves your problem. I always go by the rule, First make it work, then make it work better ;) -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 06:36:26 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 18:06:26 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > Good to hear that the error went away. > > Umm yes I have had this error you are talking about. What I have done > in that case was sign the jar files with my certificate. Note that > where I was working we were distributing java programs via JNLP > internally on our WAN so it was nothing anyone outside the company > would use. I would even remove other certificates from jar files and > replace them with our own, this was a problem I had when I jar file > was signed by 2 different people. > > So try to sign the RXTXcomm.jar and see if that solves your problem. > > I always go by the rule, First make it work, then make it work better ;) going by your rule :) -> 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error that in a jnlp, jar have different signature. 2. I dont know how to unsign a jar, so I created seperate jnlp's for each jar, and added as extension, in the main jnlp file. That works :) 3) Now I am looking for improvements. How do we unsign a already signed third party jar file. saw some ANT(?) scripts, but could make little sense from that. ex: http://frank.neatstep.com/node/29 Thanks! Regards Naman From george.dma at gmail.com Tue Sep 21 06:49:07 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 15:49:07 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 3:36 PM, naman jain wrote: >> Good to hear that the error went away. >> >> Umm yes I have had this error you are talking about. What I have done >> in that case was sign the jar files with my certificate. Note that >> where I was working we were distributing java programs via JNLP >> internally on our WAN so it was nothing anyone outside the company >> would use. I would even remove other certificates from jar files and >> replace them with our own, this was a problem I had when I jar file >> was signed by 2 different people. >> >> So try to sign the RXTXcomm.jar and see if that solves your problem. >> >> I always go by the rule, First make it work, then make it work better ;) > > going by your rule :) ?-> > > 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error > that in a jnlp, jar have different signature. > > 2. I dont know how to unsign a jar, so I created seperate jnlp's for > each jar, and added as extension, > in the main jnlp file. > > > > > > > > > > That works :) > > 3) Now I am looking for improvements. How do we unsign a already > signed third party jar file. > saw some ANT(?) ?scripts, but could make little sense from that. > ?ex: http://frank.neatstep.com/node/29 > > Thanks! > > Regards > Naman Cool. When a jar is signed there are some extra files added inside the manifest folder, I believe. You could use that link, I used to just open the jar file with WinZIP and just delete the certificates in the manifest. And then sign the jar so its has only 1 signature. Though doing the extensions is more proper to show that your RXTXcomm jar came from a credible authority. Whatever you security needs are go for it. -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 07:03:33 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 18:33:33 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > Cool. > > When a jar is signed there are some extra files added inside the > manifest folder, I believe. You could use that link, I used to just > open the jar file with WinZIP and just delete the certificates in the > manifest. And then sign the jar so its has only 1 signature. Though > doing the extensions is more proper to show that your RXTXcomm jar > came from a credible authority. Whatever you security needs are go for > it. Thanks a ton ! I ll check it out. From george.dma at gmail.com Tue Sep 21 07:10:20 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 16:10:20 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 3:36 PM, naman jain wrote: >> Good to hear that the error went away. >> >> Umm yes I have had this error you are talking about. What I have done >> in that case was sign the jar files with my certificate. Note that >> where I was working we were distributing java programs via JNLP >> internally on our WAN so it was nothing anyone outside the company >> would use. I would even remove other certificates from jar files and >> replace them with our own, this was a problem I had when I jar file >> was signed by 2 different people. >> >> So try to sign the RXTXcomm.jar and see if that solves your problem. >> >> I always go by the rule, First make it work, then make it work better ;) > > going by your rule :) ?-> > > 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error > that in a jnlp, jar have different signature. > > 2. I dont know how to unsign a jar, so I created seperate jnlp's for > each jar, and added as extension, > in the main jnlp file. > > > > > > > > > > That works :) > > 3) Now I am looking for improvements. How do we unsign a already > signed third party jar file. > saw some ANT(?) ?scripts, but could make little sense from that. > ?ex: http://frank.neatstep.com/node/29 > > Thanks! > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > btw, that un-sign jar ant-script all it basically does is unjars the jar file in a directory. Deletes all files *.SF *.DSA *.RSA and then re-jars everything and signs the jar. So you can do this manually or use the script. From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:38:31 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:38:31 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: it sends 5 bytes, \r\n are printed and the output goes on the next line as a side effect (sorry if i did not point it out). anyway the code: sh.write("1TS\r\n"); where sh.write does this: public void write(String s) throws IOException { debug(String.format(">>> %s", s)); outputStream.write(s.getBytes()); } outputStream is a bare OutputStream obtained from the serial port on the reading side i use a buffered reader to read lines, the doc states that a line is ended by \n or \r\n so it should be platform indepentent public String readLine() throws IOException { String s = reader.readLine(); debug(String.format("<<< %s", s)); return s; } reader is a BufferedReader built around the serialport input stream reader = new BufferedReader(new InputStreamReader(is)); 2010/9/15 Kustaa Nyholm > > > > > The output i reported is written by my java application when it sends and > when > > it receive. > > I still do not quite understand what happens at the code level. > > Your program outputs: > > > On linux instead i have this: > > > > 2010-09-07 12.16.40: >>> 1TS > > timeout > > 2010-09-07 12.16.42: >>> 1TS > > 2010-09-07 12.16.42: <<< 3 > > 2010-09-07 12.16.43: >>> 1TS > > timeout > > So your code sends '1TS' and then get timeout? On write? > > Why it only send three bytes, or how do you know it only sends three bytes, > what I'm trying to say is that if I had programmed this the code would look > something like: > > outstream.write(bytestosend,0,bytestosend.length); > > and thus I would not know that I've only sent three bytes. So evidently > your code is different and that's why I suggested that it might be > helpful to actually see the code. > > Or am I missing something here? > > 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 andy at g0poy.com Wed Sep 15 07:40:16 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 15 Sep 2010 14:40:16 +0100 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915144016.2630de90@g0poy-server.site> Would strace help you? I've seen some references to this particularly with the -e read=set and -e write=set options. Trouble is, that I don't fully understand strace :-( Andy On Wed, 15 Sep 2010 14:42:23 +0200 Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm > > > > > >> The protocol used is an ascii protocol with CR/LF terminator for > > messages. > > > > In Windows CR/LF is often used in line termination and this convention > > is buried in lots of code ... whereas in *nix world LF only is used. > > > > So could this be related to your issue? > > > > It could be helpful if you described how you grabbed the dump > > of what is happening, now it is unclear weather you have > > observed the communication on the PC side, or device side, or > > on the actual serial communication line. > > > > Also it might be useful to show the code that actually read/write > > the port, not just the port initialization. > > > > br Kusti > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From hybris0 at gmail.com Wed Sep 15 07:40:04 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:04 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: i was not able to get it work....it does not capture anything.... 2010/9/15 George H > On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > > The output i reported is written by my java application when it sends and > > when it receive. > > As i said under linux i do not have a powerful tool like portmon on > windows > > (funny because usually is the other way round) > > > > Will this work ? http://www.rolf-schroedter.de/moni/ > > -- > George H > george.dma at gmail.com > > > The read and write is pretty simple and is done using the streams coming > > from the serial ports and yes, after each write i do a flush, even if i > do > > not use buffered streams because i saw it must be done otherwise stuff > > remains on the pc side. > > > > > > 2010/9/15 Kustaa Nyholm > >> > >> >> The protocol used is an ascii protocol with CR/LF terminator for > >> >> messages. > >> > >> In Windows CR/LF is often used in line termination and this convention > >> is buried in lots of code ... whereas in *nix world LF only is used. > >> > >> So could this be related to your issue? > >> > >> It could be helpful if you described how you grabbed the dump > >> of what is happening, now it is unclear weather you have > >> observed the communication on the PC side, or device side, or > >> on the actual serial communication line. > >> > >> Also it might be useful to show the code that actually read/write > >> the port, not just the port initialization. > >> > >> br Kusti > >> > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:40:59 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:59 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <1CD57CB0C6974785BFAB43E383D60295@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: the device requires XON/XOFF i don't get the hint about Netbeans that, btw i am using. 2010/9/15 M.Dec-GM > And what about this problem - how it works WITHOUT XON/XOFF? > Assuming (with overhead) 12 bits per byte and 12 bytes, your > transmission duration is 2.5 ms. > If you said that system is enough fast, should find 2,5 ms in each second > to serve this packet :) > > BTW: Netbeans for Linux is very easy to install and use.... no differences > :) > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 2:48 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > I am working on a PC, no PDAs....i exclude the fact that linux is too slow. > I already used RXTX under linux with no problem at all. > Also, since i was not unable to debug the application in Linux i debugged > it in Windows running in a virtual machine under the same Linux. > > Even if XON/XOFF is so simple i keep its implementations as a last resort. > Fortunately i develop on Linux but, in this case, deploy on windows so i > can workaround it this way.... debugging is a bit tedious done this way but > the protocol is sufficiently simple to not require too much debugging. In > fact i am done with it. > > I already tried to link to the RXTX sources but it seems that the flow > control stuff is done in the C part. > > 2010/9/15 M.Dec-GMail > >> Ok, >> Have you a Java source of the application? >> >> If yes, you may do a trick, which I did when I was fighting with close() >> in Linux :) >> I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to >> the application folder. >> >> !!! >> You have to remove EACH copy of the RXTX.jar from the system, and stay >> with application sources with RXTX inside. >> !!! >> >> In this case you will have very deep access to RXTX sources >> Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF >> codes. >> >> As a final/least solution is own XON/XOFF protocoll - very simple - >> believe me :) >> I think that it will be faster to write than looking for Linux >> codes/problems. >> >> OR >> >> maybe there is a Java software mistake in Serial service which is better >> visible/more critical in Linux? >> >> Switch XON/XOFF at all and try how it works. >> You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, >> assumming 10 bytes of data + CRLF. >> >> OR >> Another idea - try to send device's XON after first query... >> >> 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - >> what the computer is this - PC or small PDA, ARM? >> >> Mariusz >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 1:56 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> The protocol is not binary and the device works only that way. >> >> I'll do some of the checks you mentioned but it seems fair to me expecting >> rxtx to behave the same way on windows and linux. >> >> I recognize that it can also be a buffer problem, or a XON/XOFF value >> problem....unfortunately linux does not offer any decent tool for sniffing >> the serial at OS level as far as i know. >> >> 2010/9/15 M.Dec-GM >> >>> Hi, >>> Using XON-XOFF software handshake protocol has a some limitations - bytes >>> for XON and for XOFF are not usable, so you shouldn't transfer binary data >>> through channel. >>> This is why I am not using this protocol at all. >>> But it isn't answer yet :) >>> >>> Maybe this helps: >>> 1. Please check if codes for XON/XOFF are identical in host and client. >>> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >>> be defined by user and I did a mistake - I have forgotten to switch >>> automatic XON/XOFF in tool, but both codes were 0x00 by default... >>> You know what it means when binary data were transmitted... crazy :). >>> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >>> only... >>> 4. Looking on the problem from another side - think if XON/XOFF is >>> necessary for now, maybe bigger buffer will be enough, or simply write >>> yourself the >>> service for XON/XOFF - this very easy, and you may use my examples for >>> this job. >>> There is enough to check XOFF in SerialReader and stop writing until XON >>> will come... >>> >>> Good luck :) >>> Mariusz >>> >>> >>> >>> >>> ----- Original Message ----- >>> *From:* Hybris >>> *To:* rxtx at qbang.org >>> *Sent:* Wednesday, September 15, 2010 12:46 PM >>> *Subject:* Re: [Rxtx] XON XOFF under linux >>> >>> Nobody can help on this? >>> >>> 2010/9/7 Hybris >>> >>>> Hi, >>>> i have a problem under Linux. >>>> I often used the library (last stable release 2.1) without any problem >>>> in this environment. >>>> >>>> Without any other clues at the moment i am blaming the fact i am >>>> talking a device that requires XON/XOFF as flow control method. A >>>> method i never used before. >>>> >>>> Under windows i have no problems, under Linux commands are received by >>>> the device but i do not get replies or i get truncated replies (log >>>> follows) >>>> >>>> I am using the seial port builtin the motherboard, no usb converters. >>>> >>>> I initialize the port this way: >>>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>>> serialPort.setInputBufferSize(256); >>>> serialPort.setOutputBufferSize(256); >>>> serialPort.enableReceiveTimeout(1000); >>>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>>> >>>> The protocol used is an ascii protocol with CR/LF terminator for >>>> messages. >>>> >>>> The output i get on windows for a cycle of request/response (one per >>>> second) is this (>>> from PC to the device, <<< from device to PC): >>>> >>>> 2010-09-07 12.18.07: <<< 1TS000033 >>>> 2010-09-07 12.18.08: >>> 1TS >>>> 2010-09-07 12.18.08: <<< 1TS000033 >>>> 2010-09-07 12.18.09: >>> 1TS >>>> 2010-09-07 12.18.09: <<< 1TS000033 >>>> 2010-09-07 12.18.10: >>> 1TS >>>> 2010-09-07 12.18.10: <<< 1TS000033 >>>> 2010-09-07 12.18.11: >>> 1TS >>>> 2010-09-07 12.18.11: <<< 1TS000033 >>>> >>>> On linux instead i have this: >>>> >>>> 2010-09-07 12.16.40: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.42: >>> 1TS >>>> 2010-09-07 12.16.42: <<< 3 >>>> 2010-09-07 12.16.43: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.45: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.47: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.49: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.51: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.53: >>> 1TS >>>> 2010-09-07 12.16.53: <<< 3 >>>> 2010-09-07 12.16.54: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.56: >>> 1TS >>>> 2010-09-07 12.16.56: <<< 1TS000033 >>>> 2010-09-07 12.16.57: >>> 1TS >>>> 2010-09-07 12.16.58: <<< 3 >>>> 2010-09-07 12.16.59: >>> 1TS >>>> timeout >>>> 2010-09-07 12.17.01: >>> 1TS >>>> timeout >>>> >>>> Any ideas? >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 15 07:55:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:55:58 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com><95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: Hi Steffen, > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports Currently I am using Windows application (USB CAN reader for my car) where is the default list of the ports (COM64 is the highest one). Additionally I am using a lot of USB dongles simultaneously (about 20, up to 4 in one of applications) and there is no way to remember which COM number has THIS dongle on laptop or on desktop or in another USB socket... The same with CAN reader... And therefore I am very happy when I see available ports only - the highest number of the COM which I have used in last weeks was COM249 :). Have you used such COM port number? :) I have had to clean registry quite often... I think that now you understand my point of view on hardcoded COM ports list :))) Regards Mariusz From tjarvi at qbang.org Wed Sep 15 07:36:32 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Sep 2010 07:36:32 -0600 (MDT) Subject: [Rxtx] JNA In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: On Wed, 15 Sep 2010, Steffen DETTMER wrote: > * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: >> Hi all, >> So - this:part looks crazy: >>> // In case of errors, list COM1 through COM9 - it is better than nothing. >>> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for > > maybe better: `a doubtful'? > >> list [...]: "it is better than nothing", >> if such list gives no useful information... >> >> Please try to connect to the port from this list.... "Better >> than nothing" is to write - No ports, List Error or something >> like that... > > Indeed the application shall have a way to notice the problem > that should never occure. Also, a better fallback probably would > be the classic port enumeration code (althrough I also dislike if > this `probing' modifies control lines of those ports; but I'm not > neutral here anyway, because I dislike such `browsing' stuff and > would prefere to be able to enter the port name to use, as used > to be on classic unices and even if the serial port happens to be > a terminal or even a FIFO, almost everything works). > > Also, it might be insufficient to present the list of currently > available serial ports, for example in a configuration dialog I > may wish to configure ports which currently are not connected. > AFAIK, this for example is simply not possible with windows > hardware device manager, because in case the USB device is not > plugged you have it in no list where you could click it; bad... > So I think a good application should allow users to specify ports > directly anyway and no such fallback would be required. > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports > usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, > so such a fallback could help the majority of users where both > registry lookup and `port probing' fail. Of course it is hard to > tell what will happen on systems of the windows users where > registry lookups fail, probably nothing will work anyway, but who > knows :) > I'd just add that laptops are the most common computer people use today and very few actually have serial ports out of the box. No ports available is a useful answer. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Sep 15 08:04:50 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 17:04:50 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > it sends 5 bytes, \r\n are printed and the output goes on the next line as a > side effect (sorry if i did not point it out). > > anyway the code: > > sh.write("1TS\r\n"); > > where sh.write does this: > > public void write(String s) throws IOException { > ??????? debug(String.format(">>> %s", s)); > ??????? outputStream.write(s.getBytes()); > } Java doc for String.getBytes() says: "Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array." Could it be that the default charset on your Linux system is different from Windows and this messes things up? > > outputStream is a bare OutputStream obtained from the serial port > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent > > public String readLine() throws IOException { > ??????? String s = reader.readLine(); > ??????? debug(String.format("<<< %s", s)); > ??????? return s; > ??? } > > reader is a BufferedReader built around the serialport input stream > reader = new BufferedReader(new InputStreamReader(is)); > > Nothing strikes me as suspicious above. But I still do not understand this, you said (for Windows): >>> 2010-09-07 12.1807: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 ' where does that '000033 come and why it is different in the Linux case? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 08:08:32 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:08:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915140832.GF7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > As i said under linux i do not have a powerful tool like portmon on > windows (funny because usually is the other way round) > The read and write is pretty simple could `strace -e open,read,write -p ' help maybe? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:12:49 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:12:49 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2><1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <05754F9E14B746D1B81F2827F7E738F6@mdam2> Sorry, but finally I don't understand... You have written: ----> the device requires XON/XOFF I know it from tenths of years, but I have checked once again: http://en.wikipedia.org/wiki/Software_flow_control Flow control is necessary when one of the communication sides can't receive data because of somewhat... So if transmission is fast and short, and machines are fast, XON/XOFF signals NEVER occurs. Execptions....? ... exception I see now as possible one is the initalisation of the transmission, but in this case YOU should try to send XON. Mariusz From hybris0 at gmail.com Wed Sep 15 08:16:48 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:16:48 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: 2010/9/15 Kustaa Nyholm > > Could it be that the default charset on your Linux system is different from > Windows and this messes things up? > > yes it could but since i use only ASCII it could not. Anyway i just tested it and the list of bytes generated is correct so the problem is not there. > But I still do not understand this, you said (for Windows): [...] > > where does that '000033 come and why it is different in the Linux case? > > 1TS000033 is the reply from the device at the command 1TS the linux case is different imho because the flow control is messing things up....but i can't prove it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:19:37 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:19:37 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <20100915141937.GG7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 15:40 +0200: > And what about this problem - how it works WITHOUT XON/XOFF? I'm not sure if I understand the question correctly, but in case it helps: If you are able to always receive full speed (e.g. because on a fine PC) and you write slowing (some Thread.Sleep(50) per each few bytes or so), you should never need to send XOFF and the device should never need to do so; maybe you need to send XON once at the begin (if device starts in XOFF) but everything else should work `transparently' in this special case (i.e. PC is receiving fast but sending slowly). You told you're working on linux; here shell console windows (xterm etc) are XON/XOFF (CTRL-Q / CTRL-S), so you know how it works: as long as you don't press CTRL-S, text scrolls through. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From hybris0 at gmail.com Wed Sep 15 08:26:58 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:26:58 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <05754F9E14B746D1B81F2827F7E738F6@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> <05754F9E14B746D1B81F2827F7E738F6@mdam2> Message-ID: i understand your point and i admit ignorance on how XON/XOFF worked.... i have to assume some things as blackboxes sometimes otherwise i'll go crazy i'll investigate further 2010/9/15 M.Dec-GM > Sorry, but finally I don't understand... > You have written: > ----> the device requires XON/XOFF > > I know it from tenths of years, but I have checked once again: > http://en.wikipedia.org/wiki/Software_flow_control > > Flow control is necessary when one of the communication sides can't receive > data because of somewhat... > So if transmission is fast and short, and machines are fast, XON/XOFF > signals NEVER occurs. > > Execptions....? > ... exception I see now as possible one is the initalisation of the > transmission, but in this case YOU should try to send XON. > > Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 08:29:08 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:29:08 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <20100915140832.GF7681@elberon.bln.de.ingenico.com> References: <20100915140832.GF7681@elberon.bln.de.ingenico.com> Message-ID: yes it could but that call also traces operation on files etc. last time i tried the output was so bloated that i gave up but i should try again 2010/9/15 Steffen DETTMER > * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > > As i said under linux i do not have a powerful tool like portmon on > > windows (funny because usually is the other way round) > > The read and write is pretty simple > > could `strace -e open,read,write -p ' help maybe? > > oki, > > Steffen > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:32:12 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:32:12 +0200 Subject: [Rxtx] JNA In-Reply-To: References: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <20100915143212.GH7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 15:55 +0200: > Additionally I am using a lot of USB dongles simultaneously > (about 20, up to 4 in one of applications) and there is no way > to remember which COM number has THIS dongle on laptop or on > desktop or in another USB socket... The same with CAN reader... > > And therefore I am very happy when I see available ports only - > the highest number of the COM which I have used in last weeks > was COM249 :). Have you used such COM port number? :) Yes, similar things happen with some USB terminals that have to reboot several time in a kind of loop for some test cases, but on linux the used device names were much more cryptic :-) Also, it even seems you can crash many PCs or their USB subsystems by pluging/unplugging and/or booting/rebooting and/or `USB-re-negiotiating' things simultanously/quickly/often enough... > I have had to clean registry quite often... > I think that now you understand my point of view on hardcoded > COM ports list :))) Yes, I do and of course you are right with your statements. I just wanted to point out that in case everything fails and the list that usually shows the available ports would be completely empty, because both methods of enumerating them failed, it could be useful in some circumstances to have then at least a list of COM1..COM10 instead of an empty one, especially in a `must not happen' case, but the application has a way to notice this of course (and I would never expect a library to perform such fallbacks unless explicitely documented - troubleshoting this would be a nightmare...). In other words, it could be considered a way to fail softer and/or to limit damage in some special cases, but as also told in this thread this should be configurable. Since the default should probably be `disabled', the whole feature is even a bit more doubtful, because in case the application is aware of this situation, it could implement a fallback (such as a text input dialog) anyway - this specific implementation surely would suit better to the applications situation. I just wanted to point out that there are situations in which a `better than nothing' fallback is suited, but I agree that this one may not being one of them (however, no need to call it with words, but the OP was even worse... but now again lets all be friends!). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:40:31 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:40:31 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: ----- Original Message ----- From: "Kustaa Nyholm" To: Sent: Wednesday, September 15, 2010 4:04 PM Subject: Re: [Rxtx] XON XOFF under linux > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent ^^^^^^ HERE may be the problem as well: "SHOULD BE" but in many cases ISN'T. Mariusz From adrian.crum at yahoo.com Wed Sep 15 08:49:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 15 Sep 2010 07:49:02 -0700 (PDT) Subject: [Rxtx] Port Discovery/Enumeration (Was: JNA) In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <582091.78813.qm@web63105.mail.re1.yahoo.com> --- On Wed, 9/15/10, Steffen DETTMER wrote: > Indeed the application shall have a way to notice the > problem > that should never occure. Also, a better fallback probably > would > be the classic port enumeration code (althrough I also > dislike if > this `probing' modifies control lines of those ports; but > I'm not > neutral here anyway, because I dislike such `browsing' > stuff and > would prefere to be able to enter the port name to use, as > used > to be on classic unices and even if the serial port happens > to be > a terminal or even a FIFO, almost everything works). Let's not forget that you can specify ports in the properties file. Automatic port discovery and enumeration is not reliable and it has bad side-effects. Improving the port discovery/enumeration code is a worthwhile goal, but in the end, a user can always specify the ports they want to use in the properties file. To me, that seems like a universally acceptable fallback method. -Adrian From hybris0 at gmail.com Wed Sep 15 08:50:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:50:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: ok guys.... now i am pissed off i developed with this thing about 4 days......compiling on linux and hell testing in windows because of this problem i managed to finish my work and happily thrown it in his box for future use under, fortunately, windows you gave me some hints, you gave me some things to think about so i take the whole stuff out of his box again, reattach all those nice connections it has and what happens it all works without changing a line of code sometimes things like this happen to me and i really do not have answers it's running now smoothly... i can't believe all the time i spent in trying to figure out what was wrong and probably i'll never know :( thanks anyway 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:18:31 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:18:31 -0400 Subject: [Rxtx] Linux build problem Message-ID: Hi I was wondering if anyone could shed some light on why I'm having the following build problem on Linux. I usually build on windows so this is a bit of a departure for me. I'm trying to build 2.2pre2 (with a few patches) but it doesn't appear like the patches are at fault here. I had a quick look through the *.in files but nothing obvious came to light. Any help would be appreciated. John Coffey $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fPIC checking if gfortran PIC flag -fPIC works... yes checking if gfortran supports -c -o file.o... yes checking whether the gfortran linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking for xcode-select... no checking java.home /usr/java/jdk1.6.0_21/jre adjusted java.home is /usr/java/jdk1.6.0_21 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.6.0_21 checking os.version 2.6.27.25-170.2.72.fc10.i686 configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:11:59] $ make /usr/java/jdk1.6.0_21/bin/javac -classpath .:/home/john/main/javacode/rxtx-devel:/home/john/main/javacode/rxtx-devel/src: -d /home/john/main/javacode/rxtx-devel/ -O -source 1.3 -target 1.3 /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortEnumerator.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortIdentifier.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortOwnershipListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Configure.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2C.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/LPRPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/NoSuchPortException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortAlreadyClosedException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortInUseException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Raw.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485Port.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXCommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXVersion.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnsupportedCommOperationException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnSupportedLoggerException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Zystem.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:138: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String IOException ex = new IOException( String.format( "Port is in use: %s ", e.currentOwner ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:164: cannot find symbol symbol : method format(java.lang.String,java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "RXTX: java %s, native %s", gnu.io.RXTXVersion.getVersion(), gnu.io.RXTXVersion.nativeGetVersion() ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:168: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "Connecting to serial port (%s)..", serialPortName ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:186: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.err.println( String.format( "IO error: %s", e.getMessage() ) ); ^ 4 errors make: *** [/home/john/main/javacode/rxtx-devel/gnu/io/CommDriver.class] Error 1 [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:12:37] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hontvari at flyordie.com Wed Sep 15 16:28:42 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Thu, 16 Sep 2010 00:28:42 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C903D25.5030301@flyordie.com> References: <4C903D25.5030301@flyordie.com> Message-ID: <4C91489A.4080304@flyordie.com> I have found a way to make it work. If the code changes flow control from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it immediately receive both the command responses and the data sent by the remote modem. It is still unclear why setting the flow control makes any difference, considering that the same procedure works in the terminal even if the terminal is set to "no flow control" or XON/XOFF flow control. On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > I want to start a data connection through a mobile phone, acting as a > modem, using AT commands. It does work in a terminal as expected. > > There is a strange behavior when I do the same thing through RXTX. The > modem should respond to the dial (ATD...) command with a CONNECT ... > message, after it successfully connected to the remote modem. It does > respond. But my code receive this message and any data the remote > modem sends only after the data transfer is completed and the modems > disconnects or after the modem temporarily goes into command state > during the session. > > There is a log below and I attached the test class which produced it. > > For the record: The phone is Siemens C55 connected through an > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > 377 Flow control: 0 > 1379 Event: Output buffer is empty (false->true) > 1380 Sent: atd+36304696729\r > 1381 Event: Output buffer is empty (false->true) > 1428 Event: Data available (false->true) > 1528 Read: atd+36304696729\r > 20758 Event: Carrier detect (false->true) > 22800 Event: Output buffer is empty (false->true) > 22800 Sent: Hello World!\r\n > 22801 Event: Output buffer is empty (false->true) > 22801 Sent: Lets go chat!\r\n > 22805 Event: Output buffer is empty (false->true) > 32802 Event: Output buffer is empty (false->true) > 32802 Sent: +++ > 32803 Event: Output buffer is empty (false->true) > 33808 Event: Data available (false->true) > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > \r\r\nOK\r\n > 35803 Event: Output buffer is empty (false->true) > 35803 Sent: ath\r > 35805 Event: Output buffer is empty (false->true) > 35860 Event: Data available (false->true) > 35962 Read: ath\r > 36266 Event: Data available (false->true) > 36367 Read: \r\nOK\r\n > 36368 Event: Carrier detect (true->false) > 37803 The End > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:50:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:50:26 -0400 Subject: [Rxtx] Linux build problem Message-ID: Fixed, sorry my bad! I had an extraneous file in my build which the auto-conf script was picking up. It's compiling now. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Sep 15 18:33:38 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 16 Sep 2010 01:33:38 +0100 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C91489A.4080304@flyordie.com> References: <4C903D25.5030301@flyordie.com> <4C91489A.4080304@flyordie.com> Message-ID: <20100916013338.2a7f78c7@g0poy-server.site> It is possible that by setting the hardware flow control it may be setting the correct conditions for the data flow to start. My first thought would be to hang a breakout box on the cable and see what (if anything) changes It would not be the first time I've found that a device set to Xon-Xoff or even no flow control needing to see the correct conditions on the hardware control lines before it would start to work correctly. windows Hyperterm is one such troublemaker, sometimes and I've never worked out what causes it, sometimes it just stops working or will not start. The only way to wake it up is to fiddle with the control lines, and eventually it starts. One company I worked for gave up recommending it as a terminal, due to the number of help calls we got, and we switched to Tera Term, and the problems went away. Andy On Thu, 16 Sep 2010 00:28:42 +0200 Hontv?ri J?zsef Levente wrote: > I have found a way to make it work. If the code changes flow control > from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it > immediately receive both the command responses and the data sent by the > remote modem. > > It is still unclear why setting the flow control makes any difference, > considering that the same procedure works in the terminal even if the > terminal is set to "no flow control" or XON/XOFF flow control. > > > On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > > I want to start a data connection through a mobile phone, acting as a > > modem, using AT commands. It does work in a terminal as expected. > > > > There is a strange behavior when I do the same thing through RXTX. The > > modem should respond to the dial (ATD...) command with a CONNECT ... > > message, after it successfully connected to the remote modem. It does > > respond. But my code receive this message and any data the remote > > modem sends only after the data transfer is completed and the modems > > disconnects or after the modem temporarily goes into command state > > during the session. > > > > There is a log below and I attached the test class which produced it. > > > > For the record: The phone is Siemens C55 connected through an > > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > > > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > 377 Flow control: 0 > > 1379 Event: Output buffer is empty (false->true) > > 1380 Sent: atd+36304696729\r > > 1381 Event: Output buffer is empty (false->true) > > 1428 Event: Data available (false->true) > > 1528 Read: atd+36304696729\r > > 20758 Event: Carrier detect (false->true) > > 22800 Event: Output buffer is empty (false->true) > > 22800 Sent: Hello World!\r\n > > 22801 Event: Output buffer is empty (false->true) > > 22801 Sent: Lets go chat!\r\n > > 22805 Event: Output buffer is empty (false->true) > > 32802 Event: Output buffer is empty (false->true) > > 32802 Sent: +++ > > 32803 Event: Output buffer is empty (false->true) > > 33808 Event: Data available (false->true) > > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > > \r\r\nOK\r\n > > 35803 Event: Output buffer is empty (false->true) > > 35803 Sent: ath\r > > 35805 Event: Output buffer is empty (false->true) > > 35860 Event: Data available (false->true) > > 35962 Read: ath\r > > 36266 Event: Data available (false->true) > > 36367 Read: \r\nOK\r\n > > 36368 Event: Carrier detect (true->false) > > 37803 The End > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Sep 17 06:18:58 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 14:18:58 +0200 Subject: [Rxtx] well known disconnect and crash problem Message-ID: <201009171418.58406.lucio@sulweb.org> Hello *, I'd need a version of rxtx without the "crash on disconnect" problem. I've read a few posts claiming a java-only solution, while some other offer a patch, e.g. the one attached to bug#144. What's the best way to go? Has 2.2pre2 the same problem? @Adrian Crum: do you think the rewrite is stable enough for simple reading from a single port on Linux and Windows in a production app? Thanks in advance Lucio. From mariusz.dec at gmail.com Fri Sep 17 08:14:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Fri, 17 Sep 2010 16:14:29 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> Message-ID: ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 2:18 PM Subject: [Rxtx] well known disconnect and crash problem > Hello *, > > I'd need a version of rxtx without the "crash on disconnect" problem. I've At first read carefully thread "RXTX - USB disconnecting safe and fast data transfer to app" And note that there is written about RXTX and USB disconnect. There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works in many cases. Mariusz From lucio at sulweb.org Fri Sep 17 09:07:11 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 17:07:11 +0200 Subject: [Rxtx] well known disconnect and crash problem In-Reply-To: References: <201009171418.58406.lucio@sulweb.org> Message-ID: <201009171707.11477.lucio@sulweb.org> In data venerd? 17 settembre 2010 16:14:29, M.Dec-GM ha scritto: > ----- Original Message ----- > At first read carefully thread "RXTX - USB disconnecting safe and fast data > transfer to app" And note that there is written about RXTX and USB > disconnect. Sometimes I feel the general attitude on this list not being very friendly, but I can't bet, 'cause it may very well be my poor english knowledge... never mind, could you please drop me a pointer to that thread? I subscribed to this list only 2 months ago and I have no idea where to start looking for it in the list archives. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Thanks again, Lucio. From mariusz.dec at gmail.com Fri Sep 17 11:32:32 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 17 Sep 2010 19:32:32 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> <201009171707.11477.lucio@sulweb.org> Message-ID: <986039CEE912457F87F43A281ED43768@mdam2> ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 5:07 PM There are main http://mailman.qbang.org/pipermail/rxtx/2010-September/7047577.html and next one with small improvement. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Almost 100 percent probability: - YES. But you have to good understand comments inside examples to adapt it for your code!!! In some places it looks and in fact is a bit complicated but ... works. Mariusz From namanvit at gmail.com Tue Sep 21 04:18:01 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 15:48:01 +0530 Subject: [Rxtx] error using nativelib in jnlp Message-ID: Hello, I am trying to make a COM reader in java using jnlp. So I have the files RXTXcomm.jar, rxtxwin32.dll. I have made a jar of my nativedlll -> rxtxSerial.dll.jar so my jnlp looks like: new naman.jain new new Code: I have already signed all the three jars involved here using the same certificate. Now I run it but it shows a error: Use of native libraries require unrestricted acces to the system. JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) at com.sun.javaws.Launcher.downloadResources(Unknown Source) at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) at com.sun.javaws.Launcher.launch(Unknown Source) at com.sun.javaws.Main.launchApp(Unknown Source) at com.sun.javaws.Main.continueInSecureThread(Unknown Source) at com.sun.javaws.Main$1.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could anyone please explain what could be the issue? I tried reading other related posts but could not exactly understand the cause of the problem. Regards Naman From george.dma at gmail.com Tue Sep 21 04:54:00 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 13:54:00 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 1:18 PM, naman jain wrote: > Hello, > > > I am trying to make a COM reader in java using jnlp. > > So I have the files RXTXcomm.jar, rxtxwin32.dll. > I have made a jar of my nativedlll -> rxtxSerial.dll.jar > > so my jnlp looks like: > > > ? ? > ? ? ? ?new > ? ? ? ?naman.jain > ? ? ? ? > ? ? ? ?new > ? ? ? ?new > > ? ? > > > ? ? > > > ? ? > ? ? ? ? > > > ? ? > > ? ? > > > Code: > > > > > > > > I have already signed all the three jars involved here using the same > certificate. > > Now I run it but it shows a error: > > Use of native libraries require unrestricted acces to the system. > JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] > ? at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) > ? at com.sun.javaws.Launcher.downloadResources(Unknown Source) > ? at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) > ? at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) > ? at com.sun.javaws.Launcher.launch(Unknown Source) > ? at com.sun.javaws.Main.launchApp(Unknown Source) > ? at com.sun.javaws.Main.continueInSecureThread(Unknown Source) > ? at com.sun.javaws.Main$1.run(Unknown Source) > ? at java.lang.Thread.run(Unknown Source) > > Could anyone please explain what could be the issue? > I tried reading other related posts but could not exactly understand > the cause of the problem. > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, I have had issues with native dlls and JNLP a long time ago and it is quite tricky to work. As you know programs running from JNLPs are subject to strict security which includes signing the jar file. Now you said you signed the jars so there is only 1 thing left to do. You have to explicitly tell the JNLP that the program needs unrestricted access to the system by defining a tag. Try adding this to your JNLP before the resources section. This gives full access of the jnlp app to the system. To fine tune permissions and access you should look at creating policy files which you can find at http://download.oracle.com/javase/1.4.2/docs/guide/security/permissions.html http://download-llnw.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html Hope this helps. -- George H george.dma at gmail.com From george.dma at gmail.com Tue Sep 21 04:54:00 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 13:54:00 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 1:18 PM, naman jain wrote: > Hello, > > > I am trying to make a COM reader in java using jnlp. > > So I have the files RXTXcomm.jar, rxtxwin32.dll. > I have made a jar of my nativedlll -> rxtxSerial.dll.jar > > so my jnlp looks like: > > > ? ? > ? ? ? ?new > ? ? ? ?naman.jain > ? ? ? ? > ? ? ? ?new > ? ? ? ?new > > ? ? > > > ? ? > > > ? ? > ? ? ? ? > > > ? ? > > ? ? > > > Code: > > > > > > > > I have already signed all the three jars involved here using the same > certificate. > > Now I run it but it shows a error: > > Use of native libraries require unrestricted acces to the system. > JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] > ? at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) > ? at com.sun.javaws.Launcher.downloadResources(Unknown Source) > ? at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) > ? at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) > ? at com.sun.javaws.Launcher.launch(Unknown Source) > ? at com.sun.javaws.Main.launchApp(Unknown Source) > ? at com.sun.javaws.Main.continueInSecureThread(Unknown Source) > ? at com.sun.javaws.Main$1.run(Unknown Source) > ? at java.lang.Thread.run(Unknown Source) > > Could anyone please explain what could be the issue? > I tried reading other related posts but could not exactly understand > the cause of the problem. > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, I have had issues with native dlls and JNLP a long time ago and it is quite tricky to work. As you know programs running from JNLPs are subject to strict security which includes signing the jar file. Now you said you signed the jars so there is only 1 thing left to do. You have to explicitly tell the JNLP that the program needs unrestricted access to the system by defining a tag. Try adding this to your JNLP before the resources section. This gives full access of the jnlp app to the system. To fine tune permissions and access you should look at creating policy files which you can find at http://download.oracle.com/javase/1.4.2/docs/guide/security/permissions.html http://download-llnw.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html Hope this helps. -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 05:22:54 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 16:52:54 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > I have had issues with native dlls and JNLP a long time ago and it is > quite tricky to work. As you know programs running from JNLPs are > subject to strict security which includes signing the jar file. Now > you said you signed the jars so there is only 1 thing left to do. > > You have to explicitly tell the JNLP that the program needs > unrestricted access to the system by defining a tag. Try > adding this to your JNLP before the resources section. > > > ? ? ? > Thanks for that. I put that and that error goes off. Though another ones comes in. I looks like really difficult to get it through :). now i get a error that the Jar resources in the jnlp file are not signed by same certificate. This looks a familiar error, But I have signed all three myself with a same certificate. According to my understanding, The problem should be with lib/RXTXcomm.jar as it is a third party jar that I downloaded. So is it signed by some other certificate beforehand. what do we do in such cases, I saw people writing somewher to make a seperate jnlp for RXTXcomm.jar ? Your comments on that. Regards Naman From george.dma at gmail.com Tue Sep 21 05:33:11 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 14:33:11 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 2:22 PM, naman jain wrote: >> I have had issues with native dlls and JNLP a long time ago and it is >> quite tricky to work. As you know programs running from JNLPs are >> subject to strict security which includes signing the jar file. Now >> you said you signed the jars so there is only 1 thing left to do. >> >> You have to explicitly tell the JNLP that the program needs >> unrestricted access to the system by defining a tag. Try >> adding this to your JNLP before the resources section. >> >> >> ? ? ? >> > > Thanks for that. I put that and that error goes off. Though another > ones comes in. > I looks like really difficult to get it through :). > > now i get a error that the > Jar resources in the jnlp file are not signed by same certificate. > > This looks a familiar error, But I have signed all three myself with a > same certificate. > According to my understanding, The problem should be with > lib/RXTXcomm.jar as it is a third party jar that > I downloaded. So is it signed by some other certificate beforehand. > > what do we do in such cases, I saw people writing somewher to make a > seperate jnlp for > RXTXcomm.jar ? > > Your comments on that. > > Regards > Naman Good to hear that the error went away. Umm yes I have had this error you are talking about. What I have done in that case was sign the jar files with my certificate. Note that where I was working we were distributing java programs via JNLP internally on our WAN so it was nothing anyone outside the company would use. I would even remove other certificates from jar files and replace them with our own, this was a problem I had when I jar file was signed by 2 different people. So try to sign the RXTXcomm.jar and see if that solves your problem. I always go by the rule, First make it work, then make it work better ;) -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 06:36:26 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 18:06:26 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > Good to hear that the error went away. > > Umm yes I have had this error you are talking about. What I have done > in that case was sign the jar files with my certificate. Note that > where I was working we were distributing java programs via JNLP > internally on our WAN so it was nothing anyone outside the company > would use. I would even remove other certificates from jar files and > replace them with our own, this was a problem I had when I jar file > was signed by 2 different people. > > So try to sign the RXTXcomm.jar and see if that solves your problem. > > I always go by the rule, First make it work, then make it work better ;) going by your rule :) -> 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error that in a jnlp, jar have different signature. 2. I dont know how to unsign a jar, so I created seperate jnlp's for each jar, and added as extension, in the main jnlp file. That works :) 3) Now I am looking for improvements. How do we unsign a already signed third party jar file. saw some ANT(?) scripts, but could make little sense from that. ex: http://frank.neatstep.com/node/29 Thanks! Regards Naman From george.dma at gmail.com Tue Sep 21 06:49:07 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 15:49:07 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 3:36 PM, naman jain wrote: >> Good to hear that the error went away. >> >> Umm yes I have had this error you are talking about. What I have done >> in that case was sign the jar files with my certificate. Note that >> where I was working we were distributing java programs via JNLP >> internally on our WAN so it was nothing anyone outside the company >> would use. I would even remove other certificates from jar files and >> replace them with our own, this was a problem I had when I jar file >> was signed by 2 different people. >> >> So try to sign the RXTXcomm.jar and see if that solves your problem. >> >> I always go by the rule, First make it work, then make it work better ;) > > going by your rule :) ?-> > > 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error > that in a jnlp, jar have different signature. > > 2. I dont know how to unsign a jar, so I created seperate jnlp's for > each jar, and added as extension, > in the main jnlp file. > > > > > > > > > > That works :) > > 3) Now I am looking for improvements. How do we unsign a already > signed third party jar file. > saw some ANT(?) ?scripts, but could make little sense from that. > ?ex: http://frank.neatstep.com/node/29 > > Thanks! > > Regards > Naman Cool. When a jar is signed there are some extra files added inside the manifest folder, I believe. You could use that link, I used to just open the jar file with WinZIP and just delete the certificates in the manifest. And then sign the jar so its has only 1 signature. Though doing the extensions is more proper to show that your RXTXcomm jar came from a credible authority. Whatever you security needs are go for it. -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 07:03:33 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 18:33:33 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > Cool. > > When a jar is signed there are some extra files added inside the > manifest folder, I believe. You could use that link, I used to just > open the jar file with WinZIP and just delete the certificates in the > manifest. And then sign the jar so its has only 1 signature. Though > doing the extensions is more proper to show that your RXTXcomm jar > came from a credible authority. Whatever you security needs are go for > it. Thanks a ton ! I ll check it out. From george.dma at gmail.com Tue Sep 21 07:10:20 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 16:10:20 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 3:36 PM, naman jain wrote: >> Good to hear that the error went away. >> >> Umm yes I have had this error you are talking about. What I have done >> in that case was sign the jar files with my certificate. Note that >> where I was working we were distributing java programs via JNLP >> internally on our WAN so it was nothing anyone outside the company >> would use. I would even remove other certificates from jar files and >> replace them with our own, this was a problem I had when I jar file >> was signed by 2 different people. >> >> So try to sign the RXTXcomm.jar and see if that solves your problem. >> >> I always go by the rule, First make it work, then make it work better ;) > > going by your rule :) ?-> > > 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error > that in a jnlp, jar have different signature. > > 2. I dont know how to unsign a jar, so I created seperate jnlp's for > each jar, and added as extension, > in the main jnlp file. > > > > > > > > > > That works :) > > 3) Now I am looking for improvements. How do we unsign a already > signed third party jar file. > saw some ANT(?) ?scripts, but could make little sense from that. > ?ex: http://frank.neatstep.com/node/29 > > Thanks! > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > btw, that un-sign jar ant-script all it basically does is unjars the jar file in a directory. Deletes all files *.SF *.DSA *.RSA and then re-jars everything and signs the jar. So you can do this manually or use the script. From namanvit at gmail.com Tue Sep 21 08:37:04 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 20:07:04 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > btw, that un-sign jar ant-script all it basically does is unjars the > jar file in a directory. Deletes all files *.SF *.DSA *.RSA and then > re-jars everything and signs the jar. So you can do this manually or > use the script. Ohkay. I get it. From bschlining at gmail.com Tue Sep 21 09:59:59 2010 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 21 Sep 2010 08:59:59 -0700 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > > I am trying to make a COM reader in java using jnlp. > > I use rxtx in JNLP files with no problems. Here's the steps: 1) Jar up your dll (I'm calling *rxtx-native-windows.jar*) 2) Sign the jar containing the DLL 3) Add the following to your JNLP: 4) Also add this to your JNLP Cheers -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Tue Sep 21 10:02:17 2010 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 21 Sep 2010 09:02:17 -0700 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: p.s. you Can target multiple OS's too in the same JNLP. Just jar up each .dll, .so or .jnilib in it's own jar. Here's a JNLP snippet sample: On Tue, Sep 21, 2010 at 08:59, Brian Schlining wrote: > I am trying to make a COM reader in java using jnlp. >> >> > I use rxtx in JNLP files with no problems. Here's the steps: > 1) Jar up your dll (I'm calling *rxtx-native-windows.jar*) > 2) Sign the jar containing the DLL > 3) Add the following to your JNLP: > > > > 4) Also add this to your JNLP > > > > > > > Cheers > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From namanvit at gmail.com Wed Sep 22 06:05:14 2010 From: namanvit at gmail.com (naman jain) Date: Wed, 22 Sep 2010 17:35:14 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: Thanks brian. I get it. From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:38:31 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:38:31 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: it sends 5 bytes, \r\n are printed and the output goes on the next line as a side effect (sorry if i did not point it out). anyway the code: sh.write("1TS\r\n"); where sh.write does this: public void write(String s) throws IOException { debug(String.format(">>> %s", s)); outputStream.write(s.getBytes()); } outputStream is a bare OutputStream obtained from the serial port on the reading side i use a buffered reader to read lines, the doc states that a line is ended by \n or \r\n so it should be platform indepentent public String readLine() throws IOException { String s = reader.readLine(); debug(String.format("<<< %s", s)); return s; } reader is a BufferedReader built around the serialport input stream reader = new BufferedReader(new InputStreamReader(is)); 2010/9/15 Kustaa Nyholm > > > > > The output i reported is written by my java application when it sends and > when > > it receive. > > I still do not quite understand what happens at the code level. > > Your program outputs: > > > On linux instead i have this: > > > > 2010-09-07 12.16.40: >>> 1TS > > timeout > > 2010-09-07 12.16.42: >>> 1TS > > 2010-09-07 12.16.42: <<< 3 > > 2010-09-07 12.16.43: >>> 1TS > > timeout > > So your code sends '1TS' and then get timeout? On write? > > Why it only send three bytes, or how do you know it only sends three bytes, > what I'm trying to say is that if I had programmed this the code would look > something like: > > outstream.write(bytestosend,0,bytestosend.length); > > and thus I would not know that I've only sent three bytes. So evidently > your code is different and that's why I suggested that it might be > helpful to actually see the code. > > Or am I missing something here? > > 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 andy at g0poy.com Wed Sep 15 07:40:16 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 15 Sep 2010 14:40:16 +0100 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915144016.2630de90@g0poy-server.site> Would strace help you? I've seen some references to this particularly with the -e read=set and -e write=set options. Trouble is, that I don't fully understand strace :-( Andy On Wed, 15 Sep 2010 14:42:23 +0200 Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm > > > > > >> The protocol used is an ascii protocol with CR/LF terminator for > > messages. > > > > In Windows CR/LF is often used in line termination and this convention > > is buried in lots of code ... whereas in *nix world LF only is used. > > > > So could this be related to your issue? > > > > It could be helpful if you described how you grabbed the dump > > of what is happening, now it is unclear weather you have > > observed the communication on the PC side, or device side, or > > on the actual serial communication line. > > > > Also it might be useful to show the code that actually read/write > > the port, not just the port initialization. > > > > br Kusti > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From hybris0 at gmail.com Wed Sep 15 07:40:04 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:04 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: i was not able to get it work....it does not capture anything.... 2010/9/15 George H > On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > > The output i reported is written by my java application when it sends and > > when it receive. > > As i said under linux i do not have a powerful tool like portmon on > windows > > (funny because usually is the other way round) > > > > Will this work ? http://www.rolf-schroedter.de/moni/ > > -- > George H > george.dma at gmail.com > > > The read and write is pretty simple and is done using the streams coming > > from the serial ports and yes, after each write i do a flush, even if i > do > > not use buffered streams because i saw it must be done otherwise stuff > > remains on the pc side. > > > > > > 2010/9/15 Kustaa Nyholm > >> > >> >> The protocol used is an ascii protocol with CR/LF terminator for > >> >> messages. > >> > >> In Windows CR/LF is often used in line termination and this convention > >> is buried in lots of code ... whereas in *nix world LF only is used. > >> > >> So could this be related to your issue? > >> > >> It could be helpful if you described how you grabbed the dump > >> of what is happening, now it is unclear weather you have > >> observed the communication on the PC side, or device side, or > >> on the actual serial communication line. > >> > >> Also it might be useful to show the code that actually read/write > >> the port, not just the port initialization. > >> > >> br Kusti > >> > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:40:59 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:59 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <1CD57CB0C6974785BFAB43E383D60295@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: the device requires XON/XOFF i don't get the hint about Netbeans that, btw i am using. 2010/9/15 M.Dec-GM > And what about this problem - how it works WITHOUT XON/XOFF? > Assuming (with overhead) 12 bits per byte and 12 bytes, your > transmission duration is 2.5 ms. > If you said that system is enough fast, should find 2,5 ms in each second > to serve this packet :) > > BTW: Netbeans for Linux is very easy to install and use.... no differences > :) > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 2:48 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > I am working on a PC, no PDAs....i exclude the fact that linux is too slow. > I already used RXTX under linux with no problem at all. > Also, since i was not unable to debug the application in Linux i debugged > it in Windows running in a virtual machine under the same Linux. > > Even if XON/XOFF is so simple i keep its implementations as a last resort. > Fortunately i develop on Linux but, in this case, deploy on windows so i > can workaround it this way.... debugging is a bit tedious done this way but > the protocol is sufficiently simple to not require too much debugging. In > fact i am done with it. > > I already tried to link to the RXTX sources but it seems that the flow > control stuff is done in the C part. > > 2010/9/15 M.Dec-GMail > >> Ok, >> Have you a Java source of the application? >> >> If yes, you may do a trick, which I did when I was fighting with close() >> in Linux :) >> I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to >> the application folder. >> >> !!! >> You have to remove EACH copy of the RXTX.jar from the system, and stay >> with application sources with RXTX inside. >> !!! >> >> In this case you will have very deep access to RXTX sources >> Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF >> codes. >> >> As a final/least solution is own XON/XOFF protocoll - very simple - >> believe me :) >> I think that it will be faster to write than looking for Linux >> codes/problems. >> >> OR >> >> maybe there is a Java software mistake in Serial service which is better >> visible/more critical in Linux? >> >> Switch XON/XOFF at all and try how it works. >> You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, >> assumming 10 bytes of data + CRLF. >> >> OR >> Another idea - try to send device's XON after first query... >> >> 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - >> what the computer is this - PC or small PDA, ARM? >> >> Mariusz >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 1:56 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> The protocol is not binary and the device works only that way. >> >> I'll do some of the checks you mentioned but it seems fair to me expecting >> rxtx to behave the same way on windows and linux. >> >> I recognize that it can also be a buffer problem, or a XON/XOFF value >> problem....unfortunately linux does not offer any decent tool for sniffing >> the serial at OS level as far as i know. >> >> 2010/9/15 M.Dec-GM >> >>> Hi, >>> Using XON-XOFF software handshake protocol has a some limitations - bytes >>> for XON and for XOFF are not usable, so you shouldn't transfer binary data >>> through channel. >>> This is why I am not using this protocol at all. >>> But it isn't answer yet :) >>> >>> Maybe this helps: >>> 1. Please check if codes for XON/XOFF are identical in host and client. >>> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >>> be defined by user and I did a mistake - I have forgotten to switch >>> automatic XON/XOFF in tool, but both codes were 0x00 by default... >>> You know what it means when binary data were transmitted... crazy :). >>> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >>> only... >>> 4. Looking on the problem from another side - think if XON/XOFF is >>> necessary for now, maybe bigger buffer will be enough, or simply write >>> yourself the >>> service for XON/XOFF - this very easy, and you may use my examples for >>> this job. >>> There is enough to check XOFF in SerialReader and stop writing until XON >>> will come... >>> >>> Good luck :) >>> Mariusz >>> >>> >>> >>> >>> ----- Original Message ----- >>> *From:* Hybris >>> *To:* rxtx at qbang.org >>> *Sent:* Wednesday, September 15, 2010 12:46 PM >>> *Subject:* Re: [Rxtx] XON XOFF under linux >>> >>> Nobody can help on this? >>> >>> 2010/9/7 Hybris >>> >>>> Hi, >>>> i have a problem under Linux. >>>> I often used the library (last stable release 2.1) without any problem >>>> in this environment. >>>> >>>> Without any other clues at the moment i am blaming the fact i am >>>> talking a device that requires XON/XOFF as flow control method. A >>>> method i never used before. >>>> >>>> Under windows i have no problems, under Linux commands are received by >>>> the device but i do not get replies or i get truncated replies (log >>>> follows) >>>> >>>> I am using the seial port builtin the motherboard, no usb converters. >>>> >>>> I initialize the port this way: >>>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>>> serialPort.setInputBufferSize(256); >>>> serialPort.setOutputBufferSize(256); >>>> serialPort.enableReceiveTimeout(1000); >>>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>>> >>>> The protocol used is an ascii protocol with CR/LF terminator for >>>> messages. >>>> >>>> The output i get on windows for a cycle of request/response (one per >>>> second) is this (>>> from PC to the device, <<< from device to PC): >>>> >>>> 2010-09-07 12.18.07: <<< 1TS000033 >>>> 2010-09-07 12.18.08: >>> 1TS >>>> 2010-09-07 12.18.08: <<< 1TS000033 >>>> 2010-09-07 12.18.09: >>> 1TS >>>> 2010-09-07 12.18.09: <<< 1TS000033 >>>> 2010-09-07 12.18.10: >>> 1TS >>>> 2010-09-07 12.18.10: <<< 1TS000033 >>>> 2010-09-07 12.18.11: >>> 1TS >>>> 2010-09-07 12.18.11: <<< 1TS000033 >>>> >>>> On linux instead i have this: >>>> >>>> 2010-09-07 12.16.40: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.42: >>> 1TS >>>> 2010-09-07 12.16.42: <<< 3 >>>> 2010-09-07 12.16.43: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.45: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.47: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.49: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.51: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.53: >>> 1TS >>>> 2010-09-07 12.16.53: <<< 3 >>>> 2010-09-07 12.16.54: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.56: >>> 1TS >>>> 2010-09-07 12.16.56: <<< 1TS000033 >>>> 2010-09-07 12.16.57: >>> 1TS >>>> 2010-09-07 12.16.58: <<< 3 >>>> 2010-09-07 12.16.59: >>> 1TS >>>> timeout >>>> 2010-09-07 12.17.01: >>> 1TS >>>> timeout >>>> >>>> Any ideas? >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 15 07:55:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:55:58 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com><95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: Hi Steffen, > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports Currently I am using Windows application (USB CAN reader for my car) where is the default list of the ports (COM64 is the highest one). Additionally I am using a lot of USB dongles simultaneously (about 20, up to 4 in one of applications) and there is no way to remember which COM number has THIS dongle on laptop or on desktop or in another USB socket... The same with CAN reader... And therefore I am very happy when I see available ports only - the highest number of the COM which I have used in last weeks was COM249 :). Have you used such COM port number? :) I have had to clean registry quite often... I think that now you understand my point of view on hardcoded COM ports list :))) Regards Mariusz From tjarvi at qbang.org Wed Sep 15 07:36:32 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Sep 2010 07:36:32 -0600 (MDT) Subject: [Rxtx] JNA In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: On Wed, 15 Sep 2010, Steffen DETTMER wrote: > * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: >> Hi all, >> So - this:part looks crazy: >>> // In case of errors, list COM1 through COM9 - it is better than nothing. >>> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for > > maybe better: `a doubtful'? > >> list [...]: "it is better than nothing", >> if such list gives no useful information... >> >> Please try to connect to the port from this list.... "Better >> than nothing" is to write - No ports, List Error or something >> like that... > > Indeed the application shall have a way to notice the problem > that should never occure. Also, a better fallback probably would > be the classic port enumeration code (althrough I also dislike if > this `probing' modifies control lines of those ports; but I'm not > neutral here anyway, because I dislike such `browsing' stuff and > would prefere to be able to enter the port name to use, as used > to be on classic unices and even if the serial port happens to be > a terminal or even a FIFO, almost everything works). > > Also, it might be insufficient to present the list of currently > available serial ports, for example in a configuration dialog I > may wish to configure ports which currently are not connected. > AFAIK, this for example is simply not possible with windows > hardware device manager, because in case the USB device is not > plugged you have it in no list where you could click it; bad... > So I think a good application should allow users to specify ports > directly anyway and no such fallback would be required. > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports > usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, > so such a fallback could help the majority of users where both > registry lookup and `port probing' fail. Of course it is hard to > tell what will happen on systems of the windows users where > registry lookups fail, probably nothing will work anyway, but who > knows :) > I'd just add that laptops are the most common computer people use today and very few actually have serial ports out of the box. No ports available is a useful answer. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Sep 15 08:04:50 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 17:04:50 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > it sends 5 bytes, \r\n are printed and the output goes on the next line as a > side effect (sorry if i did not point it out). > > anyway the code: > > sh.write("1TS\r\n"); > > where sh.write does this: > > public void write(String s) throws IOException { > ??????? debug(String.format(">>> %s", s)); > ??????? outputStream.write(s.getBytes()); > } Java doc for String.getBytes() says: "Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array." Could it be that the default charset on your Linux system is different from Windows and this messes things up? > > outputStream is a bare OutputStream obtained from the serial port > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent > > public String readLine() throws IOException { > ??????? String s = reader.readLine(); > ??????? debug(String.format("<<< %s", s)); > ??????? return s; > ??? } > > reader is a BufferedReader built around the serialport input stream > reader = new BufferedReader(new InputStreamReader(is)); > > Nothing strikes me as suspicious above. But I still do not understand this, you said (for Windows): >>> 2010-09-07 12.1807: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 ' where does that '000033 come and why it is different in the Linux case? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 08:08:32 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:08:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915140832.GF7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > As i said under linux i do not have a powerful tool like portmon on > windows (funny because usually is the other way round) > The read and write is pretty simple could `strace -e open,read,write -p ' help maybe? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:12:49 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:12:49 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2><1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <05754F9E14B746D1B81F2827F7E738F6@mdam2> Sorry, but finally I don't understand... You have written: ----> the device requires XON/XOFF I know it from tenths of years, but I have checked once again: http://en.wikipedia.org/wiki/Software_flow_control Flow control is necessary when one of the communication sides can't receive data because of somewhat... So if transmission is fast and short, and machines are fast, XON/XOFF signals NEVER occurs. Execptions....? ... exception I see now as possible one is the initalisation of the transmission, but in this case YOU should try to send XON. Mariusz From hybris0 at gmail.com Wed Sep 15 08:16:48 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:16:48 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: 2010/9/15 Kustaa Nyholm > > Could it be that the default charset on your Linux system is different from > Windows and this messes things up? > > yes it could but since i use only ASCII it could not. Anyway i just tested it and the list of bytes generated is correct so the problem is not there. > But I still do not understand this, you said (for Windows): [...] > > where does that '000033 come and why it is different in the Linux case? > > 1TS000033 is the reply from the device at the command 1TS the linux case is different imho because the flow control is messing things up....but i can't prove it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:19:37 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:19:37 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <20100915141937.GG7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 15:40 +0200: > And what about this problem - how it works WITHOUT XON/XOFF? I'm not sure if I understand the question correctly, but in case it helps: If you are able to always receive full speed (e.g. because on a fine PC) and you write slowing (some Thread.Sleep(50) per each few bytes or so), you should never need to send XOFF and the device should never need to do so; maybe you need to send XON once at the begin (if device starts in XOFF) but everything else should work `transparently' in this special case (i.e. PC is receiving fast but sending slowly). You told you're working on linux; here shell console windows (xterm etc) are XON/XOFF (CTRL-Q / CTRL-S), so you know how it works: as long as you don't press CTRL-S, text scrolls through. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From hybris0 at gmail.com Wed Sep 15 08:26:58 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:26:58 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <05754F9E14B746D1B81F2827F7E738F6@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> <05754F9E14B746D1B81F2827F7E738F6@mdam2> Message-ID: i understand your point and i admit ignorance on how XON/XOFF worked.... i have to assume some things as blackboxes sometimes otherwise i'll go crazy i'll investigate further 2010/9/15 M.Dec-GM > Sorry, but finally I don't understand... > You have written: > ----> the device requires XON/XOFF > > I know it from tenths of years, but I have checked once again: > http://en.wikipedia.org/wiki/Software_flow_control > > Flow control is necessary when one of the communication sides can't receive > data because of somewhat... > So if transmission is fast and short, and machines are fast, XON/XOFF > signals NEVER occurs. > > Execptions....? > ... exception I see now as possible one is the initalisation of the > transmission, but in this case YOU should try to send XON. > > Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 08:29:08 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:29:08 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <20100915140832.GF7681@elberon.bln.de.ingenico.com> References: <20100915140832.GF7681@elberon.bln.de.ingenico.com> Message-ID: yes it could but that call also traces operation on files etc. last time i tried the output was so bloated that i gave up but i should try again 2010/9/15 Steffen DETTMER > * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > > As i said under linux i do not have a powerful tool like portmon on > > windows (funny because usually is the other way round) > > The read and write is pretty simple > > could `strace -e open,read,write -p ' help maybe? > > oki, > > Steffen > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:32:12 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:32:12 +0200 Subject: [Rxtx] JNA In-Reply-To: References: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <20100915143212.GH7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 15:55 +0200: > Additionally I am using a lot of USB dongles simultaneously > (about 20, up to 4 in one of applications) and there is no way > to remember which COM number has THIS dongle on laptop or on > desktop or in another USB socket... The same with CAN reader... > > And therefore I am very happy when I see available ports only - > the highest number of the COM which I have used in last weeks > was COM249 :). Have you used such COM port number? :) Yes, similar things happen with some USB terminals that have to reboot several time in a kind of loop for some test cases, but on linux the used device names were much more cryptic :-) Also, it even seems you can crash many PCs or their USB subsystems by pluging/unplugging and/or booting/rebooting and/or `USB-re-negiotiating' things simultanously/quickly/often enough... > I have had to clean registry quite often... > I think that now you understand my point of view on hardcoded > COM ports list :))) Yes, I do and of course you are right with your statements. I just wanted to point out that in case everything fails and the list that usually shows the available ports would be completely empty, because both methods of enumerating them failed, it could be useful in some circumstances to have then at least a list of COM1..COM10 instead of an empty one, especially in a `must not happen' case, but the application has a way to notice this of course (and I would never expect a library to perform such fallbacks unless explicitely documented - troubleshoting this would be a nightmare...). In other words, it could be considered a way to fail softer and/or to limit damage in some special cases, but as also told in this thread this should be configurable. Since the default should probably be `disabled', the whole feature is even a bit more doubtful, because in case the application is aware of this situation, it could implement a fallback (such as a text input dialog) anyway - this specific implementation surely would suit better to the applications situation. I just wanted to point out that there are situations in which a `better than nothing' fallback is suited, but I agree that this one may not being one of them (however, no need to call it with words, but the OP was even worse... but now again lets all be friends!). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:40:31 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:40:31 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: ----- Original Message ----- From: "Kustaa Nyholm" To: Sent: Wednesday, September 15, 2010 4:04 PM Subject: Re: [Rxtx] XON XOFF under linux > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent ^^^^^^ HERE may be the problem as well: "SHOULD BE" but in many cases ISN'T. Mariusz From adrian.crum at yahoo.com Wed Sep 15 08:49:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 15 Sep 2010 07:49:02 -0700 (PDT) Subject: [Rxtx] Port Discovery/Enumeration (Was: JNA) In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <582091.78813.qm@web63105.mail.re1.yahoo.com> --- On Wed, 9/15/10, Steffen DETTMER wrote: > Indeed the application shall have a way to notice the > problem > that should never occure. Also, a better fallback probably > would > be the classic port enumeration code (althrough I also > dislike if > this `probing' modifies control lines of those ports; but > I'm not > neutral here anyway, because I dislike such `browsing' > stuff and > would prefere to be able to enter the port name to use, as > used > to be on classic unices and even if the serial port happens > to be > a terminal or even a FIFO, almost everything works). Let's not forget that you can specify ports in the properties file. Automatic port discovery and enumeration is not reliable and it has bad side-effects. Improving the port discovery/enumeration code is a worthwhile goal, but in the end, a user can always specify the ports they want to use in the properties file. To me, that seems like a universally acceptable fallback method. -Adrian From hybris0 at gmail.com Wed Sep 15 08:50:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:50:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: ok guys.... now i am pissed off i developed with this thing about 4 days......compiling on linux and hell testing in windows because of this problem i managed to finish my work and happily thrown it in his box for future use under, fortunately, windows you gave me some hints, you gave me some things to think about so i take the whole stuff out of his box again, reattach all those nice connections it has and what happens it all works without changing a line of code sometimes things like this happen to me and i really do not have answers it's running now smoothly... i can't believe all the time i spent in trying to figure out what was wrong and probably i'll never know :( thanks anyway 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:18:31 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:18:31 -0400 Subject: [Rxtx] Linux build problem Message-ID: Hi I was wondering if anyone could shed some light on why I'm having the following build problem on Linux. I usually build on windows so this is a bit of a departure for me. I'm trying to build 2.2pre2 (with a few patches) but it doesn't appear like the patches are at fault here. I had a quick look through the *.in files but nothing obvious came to light. Any help would be appreciated. John Coffey $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fPIC checking if gfortran PIC flag -fPIC works... yes checking if gfortran supports -c -o file.o... yes checking whether the gfortran linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking for xcode-select... no checking java.home /usr/java/jdk1.6.0_21/jre adjusted java.home is /usr/java/jdk1.6.0_21 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.6.0_21 checking os.version 2.6.27.25-170.2.72.fc10.i686 configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:11:59] $ make /usr/java/jdk1.6.0_21/bin/javac -classpath .:/home/john/main/javacode/rxtx-devel:/home/john/main/javacode/rxtx-devel/src: -d /home/john/main/javacode/rxtx-devel/ -O -source 1.3 -target 1.3 /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortEnumerator.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortIdentifier.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortOwnershipListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Configure.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2C.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/LPRPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/NoSuchPortException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortAlreadyClosedException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortInUseException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Raw.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485Port.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXCommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXVersion.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnsupportedCommOperationException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnSupportedLoggerException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Zystem.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:138: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String IOException ex = new IOException( String.format( "Port is in use: %s ", e.currentOwner ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:164: cannot find symbol symbol : method format(java.lang.String,java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "RXTX: java %s, native %s", gnu.io.RXTXVersion.getVersion(), gnu.io.RXTXVersion.nativeGetVersion() ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:168: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "Connecting to serial port (%s)..", serialPortName ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:186: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.err.println( String.format( "IO error: %s", e.getMessage() ) ); ^ 4 errors make: *** [/home/john/main/javacode/rxtx-devel/gnu/io/CommDriver.class] Error 1 [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:12:37] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hontvari at flyordie.com Wed Sep 15 16:28:42 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Thu, 16 Sep 2010 00:28:42 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C903D25.5030301@flyordie.com> References: <4C903D25.5030301@flyordie.com> Message-ID: <4C91489A.4080304@flyordie.com> I have found a way to make it work. If the code changes flow control from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it immediately receive both the command responses and the data sent by the remote modem. It is still unclear why setting the flow control makes any difference, considering that the same procedure works in the terminal even if the terminal is set to "no flow control" or XON/XOFF flow control. On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > I want to start a data connection through a mobile phone, acting as a > modem, using AT commands. It does work in a terminal as expected. > > There is a strange behavior when I do the same thing through RXTX. The > modem should respond to the dial (ATD...) command with a CONNECT ... > message, after it successfully connected to the remote modem. It does > respond. But my code receive this message and any data the remote > modem sends only after the data transfer is completed and the modems > disconnects or after the modem temporarily goes into command state > during the session. > > There is a log below and I attached the test class which produced it. > > For the record: The phone is Siemens C55 connected through an > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > 377 Flow control: 0 > 1379 Event: Output buffer is empty (false->true) > 1380 Sent: atd+36304696729\r > 1381 Event: Output buffer is empty (false->true) > 1428 Event: Data available (false->true) > 1528 Read: atd+36304696729\r > 20758 Event: Carrier detect (false->true) > 22800 Event: Output buffer is empty (false->true) > 22800 Sent: Hello World!\r\n > 22801 Event: Output buffer is empty (false->true) > 22801 Sent: Lets go chat!\r\n > 22805 Event: Output buffer is empty (false->true) > 32802 Event: Output buffer is empty (false->true) > 32802 Sent: +++ > 32803 Event: Output buffer is empty (false->true) > 33808 Event: Data available (false->true) > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > \r\r\nOK\r\n > 35803 Event: Output buffer is empty (false->true) > 35803 Sent: ath\r > 35805 Event: Output buffer is empty (false->true) > 35860 Event: Data available (false->true) > 35962 Read: ath\r > 36266 Event: Data available (false->true) > 36367 Read: \r\nOK\r\n > 36368 Event: Carrier detect (true->false) > 37803 The End > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:50:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:50:26 -0400 Subject: [Rxtx] Linux build problem Message-ID: Fixed, sorry my bad! I had an extraneous file in my build which the auto-conf script was picking up. It's compiling now. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Sep 15 18:33:38 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 16 Sep 2010 01:33:38 +0100 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C91489A.4080304@flyordie.com> References: <4C903D25.5030301@flyordie.com> <4C91489A.4080304@flyordie.com> Message-ID: <20100916013338.2a7f78c7@g0poy-server.site> It is possible that by setting the hardware flow control it may be setting the correct conditions for the data flow to start. My first thought would be to hang a breakout box on the cable and see what (if anything) changes It would not be the first time I've found that a device set to Xon-Xoff or even no flow control needing to see the correct conditions on the hardware control lines before it would start to work correctly. windows Hyperterm is one such troublemaker, sometimes and I've never worked out what causes it, sometimes it just stops working or will not start. The only way to wake it up is to fiddle with the control lines, and eventually it starts. One company I worked for gave up recommending it as a terminal, due to the number of help calls we got, and we switched to Tera Term, and the problems went away. Andy On Thu, 16 Sep 2010 00:28:42 +0200 Hontv?ri J?zsef Levente wrote: > I have found a way to make it work. If the code changes flow control > from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it > immediately receive both the command responses and the data sent by the > remote modem. > > It is still unclear why setting the flow control makes any difference, > considering that the same procedure works in the terminal even if the > terminal is set to "no flow control" or XON/XOFF flow control. > > > On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > > I want to start a data connection through a mobile phone, acting as a > > modem, using AT commands. It does work in a terminal as expected. > > > > There is a strange behavior when I do the same thing through RXTX. The > > modem should respond to the dial (ATD...) command with a CONNECT ... > > message, after it successfully connected to the remote modem. It does > > respond. But my code receive this message and any data the remote > > modem sends only after the data transfer is completed and the modems > > disconnects or after the modem temporarily goes into command state > > during the session. > > > > There is a log below and I attached the test class which produced it. > > > > For the record: The phone is Siemens C55 connected through an > > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > > > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > 377 Flow control: 0 > > 1379 Event: Output buffer is empty (false->true) > > 1380 Sent: atd+36304696729\r > > 1381 Event: Output buffer is empty (false->true) > > 1428 Event: Data available (false->true) > > 1528 Read: atd+36304696729\r > > 20758 Event: Carrier detect (false->true) > > 22800 Event: Output buffer is empty (false->true) > > 22800 Sent: Hello World!\r\n > > 22801 Event: Output buffer is empty (false->true) > > 22801 Sent: Lets go chat!\r\n > > 22805 Event: Output buffer is empty (false->true) > > 32802 Event: Output buffer is empty (false->true) > > 32802 Sent: +++ > > 32803 Event: Output buffer is empty (false->true) > > 33808 Event: Data available (false->true) > > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > > \r\r\nOK\r\n > > 35803 Event: Output buffer is empty (false->true) > > 35803 Sent: ath\r > > 35805 Event: Output buffer is empty (false->true) > > 35860 Event: Data available (false->true) > > 35962 Read: ath\r > > 36266 Event: Data available (false->true) > > 36367 Read: \r\nOK\r\n > > 36368 Event: Carrier detect (true->false) > > 37803 The End > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Sep 17 06:18:58 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 14:18:58 +0200 Subject: [Rxtx] well known disconnect and crash problem Message-ID: <201009171418.58406.lucio@sulweb.org> Hello *, I'd need a version of rxtx without the "crash on disconnect" problem. I've read a few posts claiming a java-only solution, while some other offer a patch, e.g. the one attached to bug#144. What's the best way to go? Has 2.2pre2 the same problem? @Adrian Crum: do you think the rewrite is stable enough for simple reading from a single port on Linux and Windows in a production app? Thanks in advance Lucio. From mariusz.dec at gmail.com Fri Sep 17 08:14:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Fri, 17 Sep 2010 16:14:29 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> Message-ID: ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 2:18 PM Subject: [Rxtx] well known disconnect and crash problem > Hello *, > > I'd need a version of rxtx without the "crash on disconnect" problem. I've At first read carefully thread "RXTX - USB disconnecting safe and fast data transfer to app" And note that there is written about RXTX and USB disconnect. There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works in many cases. Mariusz From lucio at sulweb.org Fri Sep 17 09:07:11 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 17:07:11 +0200 Subject: [Rxtx] well known disconnect and crash problem In-Reply-To: References: <201009171418.58406.lucio@sulweb.org> Message-ID: <201009171707.11477.lucio@sulweb.org> In data venerd? 17 settembre 2010 16:14:29, M.Dec-GM ha scritto: > ----- Original Message ----- > At first read carefully thread "RXTX - USB disconnecting safe and fast data > transfer to app" And note that there is written about RXTX and USB > disconnect. Sometimes I feel the general attitude on this list not being very friendly, but I can't bet, 'cause it may very well be my poor english knowledge... never mind, could you please drop me a pointer to that thread? I subscribed to this list only 2 months ago and I have no idea where to start looking for it in the list archives. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Thanks again, Lucio. From mariusz.dec at gmail.com Fri Sep 17 11:32:32 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 17 Sep 2010 19:32:32 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> <201009171707.11477.lucio@sulweb.org> Message-ID: <986039CEE912457F87F43A281ED43768@mdam2> ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 5:07 PM There are main http://mailman.qbang.org/pipermail/rxtx/2010-September/7047577.html and next one with small improvement. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Almost 100 percent probability: - YES. But you have to good understand comments inside examples to adapt it for your code!!! In some places it looks and in fact is a bit complicated but ... works. Mariusz From namanvit at gmail.com Tue Sep 21 04:18:01 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 15:48:01 +0530 Subject: [Rxtx] error using nativelib in jnlp Message-ID: Hello, I am trying to make a COM reader in java using jnlp. So I have the files RXTXcomm.jar, rxtxwin32.dll. I have made a jar of my nativedlll -> rxtxSerial.dll.jar so my jnlp looks like: new naman.jain new new Code: I have already signed all the three jars involved here using the same certificate. Now I run it but it shows a error: Use of native libraries require unrestricted acces to the system. JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) at com.sun.javaws.Launcher.downloadResources(Unknown Source) at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) at com.sun.javaws.Launcher.launch(Unknown Source) at com.sun.javaws.Main.launchApp(Unknown Source) at com.sun.javaws.Main.continueInSecureThread(Unknown Source) at com.sun.javaws.Main$1.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could anyone please explain what could be the issue? I tried reading other related posts but could not exactly understand the cause of the problem. Regards Naman From george.dma at gmail.com Tue Sep 21 04:54:00 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 13:54:00 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 1:18 PM, naman jain wrote: > Hello, > > > I am trying to make a COM reader in java using jnlp. > > So I have the files RXTXcomm.jar, rxtxwin32.dll. > I have made a jar of my nativedlll -> rxtxSerial.dll.jar > > so my jnlp looks like: > > > ? ? > ? ? ? ?new > ? ? ? ?naman.jain > ? ? ? ? > ? ? ? ?new > ? ? ? ?new > > ? ? > > > ? ? > > > ? ? > ? ? ? ? > > > ? ? > > ? ? > > > Code: > > > > > > > > I have already signed all the three jars involved here using the same > certificate. > > Now I run it but it shows a error: > > Use of native libraries require unrestricted acces to the system. > JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] > ? at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) > ? at com.sun.javaws.Launcher.downloadResources(Unknown Source) > ? at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) > ? at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) > ? at com.sun.javaws.Launcher.launch(Unknown Source) > ? at com.sun.javaws.Main.launchApp(Unknown Source) > ? at com.sun.javaws.Main.continueInSecureThread(Unknown Source) > ? at com.sun.javaws.Main$1.run(Unknown Source) > ? at java.lang.Thread.run(Unknown Source) > > Could anyone please explain what could be the issue? > I tried reading other related posts but could not exactly understand > the cause of the problem. > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, I have had issues with native dlls and JNLP a long time ago and it is quite tricky to work. As you know programs running from JNLPs are subject to strict security which includes signing the jar file. Now you said you signed the jars so there is only 1 thing left to do. You have to explicitly tell the JNLP that the program needs unrestricted access to the system by defining a tag. Try adding this to your JNLP before the resources section. This gives full access of the jnlp app to the system. To fine tune permissions and access you should look at creating policy files which you can find at http://download.oracle.com/javase/1.4.2/docs/guide/security/permissions.html http://download-llnw.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html Hope this helps. -- George H george.dma at gmail.com From george.dma at gmail.com Tue Sep 21 04:54:00 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 13:54:00 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 1:18 PM, naman jain wrote: > Hello, > > > I am trying to make a COM reader in java using jnlp. > > So I have the files RXTXcomm.jar, rxtxwin32.dll. > I have made a jar of my nativedlll -> rxtxSerial.dll.jar > > so my jnlp looks like: > > > ? ? > ? ? ? ?new > ? ? ? ?naman.jain > ? ? ? ? > ? ? ? ?new > ? ? ? ?new > > ? ? > > > ? ? > > > ? ? > ? ? ? ? > > > ? ? > > ? ? > > > Code: > > > > > > > > I have already signed all the three jars involved here using the same > certificate. > > Now I run it but it shows a error: > > Use of native libraries require unrestricted acces to the system. > JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] > ? at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) > ? at com.sun.javaws.Launcher.downloadResources(Unknown Source) > ? at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) > ? at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) > ? at com.sun.javaws.Launcher.launch(Unknown Source) > ? at com.sun.javaws.Main.launchApp(Unknown Source) > ? at com.sun.javaws.Main.continueInSecureThread(Unknown Source) > ? at com.sun.javaws.Main$1.run(Unknown Source) > ? at java.lang.Thread.run(Unknown Source) > > Could anyone please explain what could be the issue? > I tried reading other related posts but could not exactly understand > the cause of the problem. > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, I have had issues with native dlls and JNLP a long time ago and it is quite tricky to work. As you know programs running from JNLPs are subject to strict security which includes signing the jar file. Now you said you signed the jars so there is only 1 thing left to do. You have to explicitly tell the JNLP that the program needs unrestricted access to the system by defining a tag. Try adding this to your JNLP before the resources section. This gives full access of the jnlp app to the system. To fine tune permissions and access you should look at creating policy files which you can find at http://download.oracle.com/javase/1.4.2/docs/guide/security/permissions.html http://download-llnw.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html Hope this helps. -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 05:22:54 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 16:52:54 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > I have had issues with native dlls and JNLP a long time ago and it is > quite tricky to work. As you know programs running from JNLPs are > subject to strict security which includes signing the jar file. Now > you said you signed the jars so there is only 1 thing left to do. > > You have to explicitly tell the JNLP that the program needs > unrestricted access to the system by defining a tag. Try > adding this to your JNLP before the resources section. > > > ? ? ? > Thanks for that. I put that and that error goes off. Though another ones comes in. I looks like really difficult to get it through :). now i get a error that the Jar resources in the jnlp file are not signed by same certificate. This looks a familiar error, But I have signed all three myself with a same certificate. According to my understanding, The problem should be with lib/RXTXcomm.jar as it is a third party jar that I downloaded. So is it signed by some other certificate beforehand. what do we do in such cases, I saw people writing somewher to make a seperate jnlp for RXTXcomm.jar ? Your comments on that. Regards Naman From george.dma at gmail.com Tue Sep 21 05:33:11 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 14:33:11 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 2:22 PM, naman jain wrote: >> I have had issues with native dlls and JNLP a long time ago and it is >> quite tricky to work. As you know programs running from JNLPs are >> subject to strict security which includes signing the jar file. Now >> you said you signed the jars so there is only 1 thing left to do. >> >> You have to explicitly tell the JNLP that the program needs >> unrestricted access to the system by defining a tag. Try >> adding this to your JNLP before the resources section. >> >> >> ? ? ? >> > > Thanks for that. I put that and that error goes off. Though another > ones comes in. > I looks like really difficult to get it through :). > > now i get a error that the > Jar resources in the jnlp file are not signed by same certificate. > > This looks a familiar error, But I have signed all three myself with a > same certificate. > According to my understanding, The problem should be with > lib/RXTXcomm.jar as it is a third party jar that > I downloaded. So is it signed by some other certificate beforehand. > > what do we do in such cases, I saw people writing somewher to make a > seperate jnlp for > RXTXcomm.jar ? > > Your comments on that. > > Regards > Naman Good to hear that the error went away. Umm yes I have had this error you are talking about. What I have done in that case was sign the jar files with my certificate. Note that where I was working we were distributing java programs via JNLP internally on our WAN so it was nothing anyone outside the company would use. I would even remove other certificates from jar files and replace them with our own, this was a problem I had when I jar file was signed by 2 different people. So try to sign the RXTXcomm.jar and see if that solves your problem. I always go by the rule, First make it work, then make it work better ;) -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 06:36:26 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 18:06:26 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > Good to hear that the error went away. > > Umm yes I have had this error you are talking about. What I have done > in that case was sign the jar files with my certificate. Note that > where I was working we were distributing java programs via JNLP > internally on our WAN so it was nothing anyone outside the company > would use. I would even remove other certificates from jar files and > replace them with our own, this was a problem I had when I jar file > was signed by 2 different people. > > So try to sign the RXTXcomm.jar and see if that solves your problem. > > I always go by the rule, First make it work, then make it work better ;) going by your rule :) -> 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error that in a jnlp, jar have different signature. 2. I dont know how to unsign a jar, so I created seperate jnlp's for each jar, and added as extension, in the main jnlp file. That works :) 3) Now I am looking for improvements. How do we unsign a already signed third party jar file. saw some ANT(?) scripts, but could make little sense from that. ex: http://frank.neatstep.com/node/29 Thanks! Regards Naman From george.dma at gmail.com Tue Sep 21 06:49:07 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 15:49:07 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 3:36 PM, naman jain wrote: >> Good to hear that the error went away. >> >> Umm yes I have had this error you are talking about. What I have done >> in that case was sign the jar files with my certificate. Note that >> where I was working we were distributing java programs via JNLP >> internally on our WAN so it was nothing anyone outside the company >> would use. I would even remove other certificates from jar files and >> replace them with our own, this was a problem I had when I jar file >> was signed by 2 different people. >> >> So try to sign the RXTXcomm.jar and see if that solves your problem. >> >> I always go by the rule, First make it work, then make it work better ;) > > going by your rule :) ?-> > > 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error > that in a jnlp, jar have different signature. > > 2. I dont know how to unsign a jar, so I created seperate jnlp's for > each jar, and added as extension, > in the main jnlp file. > > > > > > > > > > That works :) > > 3) Now I am looking for improvements. How do we unsign a already > signed third party jar file. > saw some ANT(?) ?scripts, but could make little sense from that. > ?ex: http://frank.neatstep.com/node/29 > > Thanks! > > Regards > Naman Cool. When a jar is signed there are some extra files added inside the manifest folder, I believe. You could use that link, I used to just open the jar file with WinZIP and just delete the certificates in the manifest. And then sign the jar so its has only 1 signature. Though doing the extensions is more proper to show that your RXTXcomm jar came from a credible authority. Whatever you security needs are go for it. -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 07:03:33 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 18:33:33 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > Cool. > > When a jar is signed there are some extra files added inside the > manifest folder, I believe. You could use that link, I used to just > open the jar file with WinZIP and just delete the certificates in the > manifest. And then sign the jar so its has only 1 signature. Though > doing the extensions is more proper to show that your RXTXcomm jar > came from a credible authority. Whatever you security needs are go for > it. Thanks a ton ! I ll check it out. From george.dma at gmail.com Tue Sep 21 07:10:20 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 16:10:20 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 3:36 PM, naman jain wrote: >> Good to hear that the error went away. >> >> Umm yes I have had this error you are talking about. What I have done >> in that case was sign the jar files with my certificate. Note that >> where I was working we were distributing java programs via JNLP >> internally on our WAN so it was nothing anyone outside the company >> would use. I would even remove other certificates from jar files and >> replace them with our own, this was a problem I had when I jar file >> was signed by 2 different people. >> >> So try to sign the RXTXcomm.jar and see if that solves your problem. >> >> I always go by the rule, First make it work, then make it work better ;) > > going by your rule :) ?-> > > 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error > that in a jnlp, jar have different signature. > > 2. I dont know how to unsign a jar, so I created seperate jnlp's for > each jar, and added as extension, > in the main jnlp file. > > > > > > > > > > That works :) > > 3) Now I am looking for improvements. How do we unsign a already > signed third party jar file. > saw some ANT(?) ?scripts, but could make little sense from that. > ?ex: http://frank.neatstep.com/node/29 > > Thanks! > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > btw, that un-sign jar ant-script all it basically does is unjars the jar file in a directory. Deletes all files *.SF *.DSA *.RSA and then re-jars everything and signs the jar. So you can do this manually or use the script. From namanvit at gmail.com Tue Sep 21 08:37:04 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 20:07:04 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > btw, that un-sign jar ant-script all it basically does is unjars the > jar file in a directory. Deletes all files *.SF *.DSA *.RSA and then > re-jars everything and signs the jar. So you can do this manually or > use the script. Ohkay. I get it. From bschlining at gmail.com Tue Sep 21 09:59:59 2010 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 21 Sep 2010 08:59:59 -0700 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > > I am trying to make a COM reader in java using jnlp. > > I use rxtx in JNLP files with no problems. Here's the steps: 1) Jar up your dll (I'm calling *rxtx-native-windows.jar*) 2) Sign the jar containing the DLL 3) Add the following to your JNLP: 4) Also add this to your JNLP Cheers -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Tue Sep 21 10:02:17 2010 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 21 Sep 2010 09:02:17 -0700 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: p.s. you Can target multiple OS's too in the same JNLP. Just jar up each .dll, .so or .jnilib in it's own jar. Here's a JNLP snippet sample: On Tue, Sep 21, 2010 at 08:59, Brian Schlining wrote: > I am trying to make a COM reader in java using jnlp. >> >> > I use rxtx in JNLP files with no problems. Here's the steps: > 1) Jar up your dll (I'm calling *rxtx-native-windows.jar*) > 2) Sign the jar containing the DLL > 3) Add the following to your JNLP: > > > > 4) Also add this to your JNLP > > > > > > > Cheers > > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From namanvit at gmail.com Wed Sep 22 06:05:14 2010 From: namanvit at gmail.com (naman jain) Date: Wed, 22 Sep 2010 17:35:14 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: Thanks brian. I get it. From jorgenovoa8 at gmail.com Wed Sep 22 16:27:37 2010 From: jorgenovoa8 at gmail.com (jorge novoa) Date: Wed, 22 Sep 2010 16:27:37 -0600 Subject: [Rxtx] Making jar files Message-ID: hi, I'm new in rxtx, i was using de java comm interface to deal with serial ports, but i been having troubles with windows 7 64 bits. I downloaded the bin rxtx 2.0 and 2.1 files but i don't understand how to make de rxtxcomm.jar file, and i can't find the information regardles on the rxtx.org and wiki sites, could you please tell me how to make the .jar file and start using it. REgards -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aaron.Baff at telescope.tv Wed Sep 22 19:30:40 2010 From: Aaron.Baff at telescope.tv (Aaron Baff) Date: Wed, 22 Sep 2010 18:30:40 -0700 Subject: [Rxtx] Getting the Serial Ports in FreeBSD Message-ID: I'm running on FreeBSD 8.1 on amd64 hardware, after having to compile the rxtx-2.2pre2 native library (rxtx-2.1-7r2 wouldn't work, some kind of 64-bit bug), I'm running into problems with CommPortIdentifier.getPortIdentifiers() not returning ANY values. The correct device is /dev/cuau0, and when I use RXTXCommDriver.getCommPort("/dev/cuau0", CommPortIdentifier.PORT_SERIAL); It returns an object so I'm guessing everything is fine (note, I haven't tried to use it, I'm using SMSLib on top of this for a GSM Modem). This is really starting to drive me up the wall, since I don't see an easy way to manually add the CommPort to the RXTXCommDriver without trying to go through some kind of subclass hoops, and maybe not even then because most of the methods/attributes are private, and what a headache that'd end up being. --Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Thu Sep 23 00:59:45 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Thu, 23 Sep 2010 08:59:45 +0200 Subject: [Rxtx] Getting the Serial Ports in FreeBSD References: Message-ID: <4FCF576745474BA590D9C6A97490ED51@mdam2> Hi, here are the answers: http://mailman.qbang.org/pipermail/rxtx/2010-June/7079738.html Regards Mariusz ----- Original Message ----- From: Aaron Baff To: rxtx at qbang.org Sent: Thursday, September 23, 2010 3:30 AM Subject: [Rxtx] Getting the Serial Ports in FreeBSD I'm running on FreeBSD 8.1 on amd64 hardware, after having to compile the rxtx-2.2pre2 native library (rxtx-2.1-7r2 wouldn't work, some kind of 64-bit bug), I'm running into problems with CommPortIdentifier.getPortIdentifiers() not returning ANY values. The correct device is /dev/cuau0, and when I use RXTXCommDriver.getCommPort("/dev/cuau0", CommPortIdentifier.PORT_SERIAL); It returns an object so I'm guessing everything is fine (note, I haven't tried to use it, I'm using SMSLib on top of this for a GSM Modem). This is really starting to drive me up the wall, since I don't see an easy way to manually add the CommPort to the RXTXCommDriver without trying to go through some kind of subclass hoops, and maybe not even then because most of the methods/attributes are private, and what a headache that'd end up being. --Aaron ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Thu Sep 23 01:17:51 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Thu, 23 Sep 2010 09:17:51 +0200 Subject: [Rxtx] Making jar files References: Message-ID: Hi. the normal way is to download sources and compile it into RXTXxxxx.jar Sometimes this may be a bit complicated for beginners. The simplest solution is to include RXTX inside application. If you are using IDE (something like NetBeans, Ecclipse...) you may copy sources to project in the similar way like another parts of the app... Thats all, and helps a lot while debugging :) I recommend using RXTX 2.2 pre, even without patches, but you may download CVS as well. Regards Mariusz ----- Original Message ----- From: jorge novoa To: rxtx at qbang.org Sent: Thursday, September 23, 2010 12:27 AM Subject: [Rxtx] Making jar files hi, I'm new in rxtx, i was using de java comm interface to deal with serial ports, but i been having troubles with windows 7 64 bits. I downloaded the bin rxtx 2.0 and 2.1 files but i don't understand how to make de rxtxcomm.jar file, and i can't find the information regardles on the rxtx.org and wiki sites, could you please tell me how to make the .jar file and start using it. REgards ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Tue Sep 7 04:22:32 2010 From: hybris0 at gmail.com (Hybris) Date: Tue, 7 Sep 2010 12:22:32 +0200 Subject: [Rxtx] XON XOFF under linux Message-ID: Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? From rbreznak at neuronrobotics.com Tue Sep 7 12:06:56 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 14:06:56 -0400 Subject: [Rxtx] Killing RXTX Message-ID: Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Tue Sep 7 14:13:32 2010 From: george.dma at gmail.com (George H) Date: Tue, 7 Sep 2010 23:13:32 +0300 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: On Tue, Sep 7, 2010 at 9:06 PM, Breznak, Robert wrote: > Maybe I am totally missing something here, so please let me know if I am. > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop > so there is a full disconnect. When I use : > serial.removeEventListener(); > serial.close(); > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > Bob > ?------------------- > ?Bob Breznak > ?1-877-474-6038 ext#701 > ?www.neuronrobotics.com Can you be a bit more specific, like is it a java thread that you are trying to kill or the underlying rxtx process ? I ask this because once with me I couldn't kill my java program because rxtx wouldn't release a resource on a printer and I was forced to reboot the pc. yeah so more info would allow us to help you better. -- George H george.dma at gmail.com From msemtd at googlemail.com Tue Sep 7 14:46:27 2010 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 7 Sep 2010 21:46:27 +0100 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: Is your application attempting to remove the event listener and close from with the event handler itself? If so, that's yer problem! regards, Michael Erskine. From rbreznak at neuronrobotics.com Tue Sep 7 15:21:34 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Tue, 7 Sep 2010 17:21:34 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: References: Message-ID: The issue that I'm experiencing is that there is a RXTX thread that is still lingering after all is said and done. It looks like its the thread for the eventLoop. What is the proper way to kill this and completely shutdown the RXTX process? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 4:46 PM, Michael Erskine wrote: > Is your application attempting to remove the event listener and close > from with the event handler itself? If so, that's yer problem! > > regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Tue Sep 7 16:36:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Tue, 7 Sep 2010 15:36:02 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <922984.18510.qm@web63105.mail.re1.yahoo.com> According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From rbreznak at neuronrobotics.com Wed Sep 8 14:36:58 2010 From: rbreznak at neuronrobotics.com (Breznak, Robert) Date: Wed, 8 Sep 2010 16:36:58 -0400 Subject: [Rxtx] Killing RXTX In-Reply-To: <922984.18510.qm@web63105.mail.re1.yahoo.com> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not > necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On *Tue, 9/7/10, Breznak, Robert * wrote: > > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX > eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct > way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 8 14:51:16 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 8 Sep 2010 22:51:16 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com> Message-ID: <7727F950FF6249568FE13031147E3731@mdam2> HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Wed Sep 8 15:10:27 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 8 Sep 2010 14:10:27 -0700 (PDT) Subject: [Rxtx] Killing RXTX In-Reply-To: Message-ID: <677082.59408.qm@web63105.mail.re1.yahoo.com> Calling the close method on an open port should not throw a memory access exception. Maybe you could provide us with more information - RXTX version, a code snippet showing the code leading up to the close method call, OS version, etc. -Adrian --- On Wed, 9/8/10, Breznak, Robert wrote: From: Breznak, Robert Subject: Re: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Wednesday, September 8, 2010, 1:36 PM My goal is to allow a user to safely disconnect a device while the application is running and then ?allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround?? Thanks,Bob? ?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob?------------------- ?Bob Breznak ?1-877-474-6038 ext#701 ?www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -----Inline Attachment Follows----- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From HowardZ at howardz.com Fri Sep 10 07:03:02 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Fri, 10 Sep 2010 09:03:02 -0400 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: References: Message-ID: <4C8A2C86.6050800@howardz.com> Hi, I have a user of my s/w having difficulties. He is using Windows 7 on a AMD CPU. He gets an exception error that the rxtx dll file can not be loaded on an AMD64 system. I have him trying the 32bit windows dll file and should hear from him later today. I build rxtx and its windows' dll files myself. Has anyone run into this problem or have any suggestions. Howard From andrea.antonello at gmail.com Fri Sep 10 08:48:55 2010 From: andrea.antonello at gmail.com (andrea antonello) Date: Fri, 10 Sep 2010 16:48:55 +0200 Subject: [Rxtx] Windows 7 OS with AMD64 architecture In-Reply-To: <4C8A2C86.6050800@howardz.com> References: <4C8A2C86.6050800@howardz.com> Message-ID: Hi, I am using the latest downloaded builds without problems on win 7. I got that message when at first I tried to load the 32bit version. So there is probably a library mismatch. Regards, Andrea On Fri, Sep 10, 2010 at 3:03 PM, HowardZ at howardz.com wrote: > ?Hi, > > I have a user of my s/w having difficulties. ?He is using Windows 7 on a AMD > CPU. > > He gets an exception error that the rxtx dll file can not be loaded on an > AMD64 system. > > I have him trying the 32bit windows dll file and should hear from him later > today. > > I build rxtx and its windows' dll files myself. > > Has anyone run into this problem or have any suggestions. > > Howard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From philipp.leusmann at rwth-aachen.de Sat Sep 11 08:43:51 2010 From: philipp.leusmann at rwth-aachen.de (Philipp Leusmann) Date: Sat, 11 Sep 2010 16:43:51 +0200 Subject: [Rxtx] Killing RXTX In-Reply-To: <7727F950FF6249568FE13031147E3731@mdam2> References: <922984.18510.qm@web63105.mail.re1.yahoo.com> <7727F950FF6249568FE13031147E3731@mdam2> Message-ID: Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: > HI > Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L > Look for the "RXTX close() problem solved", November 2009. > USb disconnection, close/re-open everything works. > > Regards > Mariusz > > > > > ----- Original Message ----- > From: Breznak, Robert > To: rxtx at qbang.org > Sent: Wednesday, September 08, 2010 10:36 PM > Subject: Re: [Rxtx] Killing RXTX > > My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: > > serial.close(); > > where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? > > Thanks, > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > > On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: > According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. > > What do you mean when you say it breaks? > > -Adrian > > --- On Tue, 9/7/10, Breznak, Robert wrote: > > From: Breznak, Robert > Subject: [Rxtx] Killing RXTX > To: rxtx at qbang.org > Date: Tuesday, September 7, 2010, 11:06 AM > > > Maybe I am totally missing something here, so please let me know if I am. > > I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : > > serial.removeEventListener(); > serial.close(); > > it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? > > Bob > ------------------- > Bob Breznak > 1-877-474-6038 ext#701 > www.neuronrobotics.com > > -----Inline Attachment Follows----- > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cougar at CasaDelGato.Com Sat Sep 11 09:06:55 2010 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Sat, 11 Sep 2010 08:06:55 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) Message-ID: <4C8B9B0F.4070609@CasaDelGato.Com> So, does anyone have a set of RxTx libs that actually WORK on a Mac? With instructions on how to install them? The distributed ones don't work, and the instructions are pretty much incomprehensible. -- -- John G. Lussmyer mailto:Cougar at CasaDelGato.Com Electric Vehicle Battery Monitoring Systems, http://www.CasaDelGato.com From Bob_Jacobsen at lbl.gov Sat Sep 11 09:35:45 2010 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Sat, 11 Sep 2010 08:35:45 -0700 Subject: [Rxtx] RxTx on a Mac (OS/X) In-Reply-To: <4C8B9B0F.4070609@CasaDelGato.Com> References: <4C8B9B0F.4070609@CasaDelGato.Com> Message-ID: I work on the JMRI project (http://jmri.org) which distributes RXTX for Mac, Windows, Linux as part of the downloads. We haven't found a single set of files that works on all Macs. We've got a combination of several files that seem to handle MacOS X 10.5 and 10.6 pretty well, but then usually have to have people mess around with three more possible versions for 10.4 until they find the one the works. I'd be very interested if somebody has a better solution. Bob On Sep 11, 2010, at 8:06 AM, John G. Lussmyer wrote: > So, does anyone have a set of RxTx libs that actually WORK on a Mac? > With instructions on how to install them? > > The distributed ones don't work, and the instructions are pretty much incomprehensible. > > -- > -- > 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 -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From mariusz.dec at gmail.com Sun Sep 12 01:06:46 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 12 Sep 2010 09:06:46 +0200 Subject: [Rxtx] Killing RXTX References: <922984.18510.qm@web63105.mail.re1.yahoo.com><7727F950FF6249568FE13031147E3731@mdam2> Message-ID: <0C47B367F65E4F628C370ECC81C79333@mdam2> Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Sun Sep 12 01:15:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Sun, 12 Sep 2010 09:15:46 +0200 Subject: [Rxtx] Killing RXTX Message-ID: <836142F8E132416AB89339D49C48B3E8@mdam2> Hi all, Update to my last post: I have forgotten to say that everything works on RXTX2.2pre before last patches and I can not guarantee nothing about 2.1.7. Application runs untouched from january 2010. Mariusz ----- Original Message ----- From: M.Dec-GMail To: rxtx at qbang.org Sent: Sunday, September 12, 2010 9:06 AM Subject: Re: [Rxtx] Killing RXTX Hi all, yes, we can say so. I have had similar problems before proper configuration of the RXTX (timeout) on L & M. After this configuration (which works in W7/Vista/XP as well) I have added threads synchronisation while closing. Both steps are NECESSARY. After this I can disconnect USB and reconnect inside working app. Only side effect while disconnecting USB are console messages from C-part of RXTX (error 0x0005). Currently (from many months) application is used on Mac & Win and I don't know about any problems. In Windows environment application works with Java updates from 16 to current 20, without problems. There is configuration with "system's copy" of Java. In Mac I don't know exactly, but I think that there is no frozen java config as well. Regards Mariusz ----- Original Message ----- From: Philipp Leusmann To: rxtx at qbang.org Sent: Saturday, September 11, 2010 4:43 PM Subject: Re: [Rxtx] Killing RXTX Is this related to this bug ? Philipp Am 08.09.2010 um 22:51 schrieb M.Dec-GM: HI Almost one year ago I have published example which shows safe open/close methods of the RXTX in W/M/L Look for the "RXTX close() problem solved", November 2009. USb disconnection, close/re-open everything works. Regards Mariusz ----- Original Message ----- From: Breznak, Robert To: rxtx at qbang.org Sent: Wednesday, September 08, 2010 10:36 PM Subject: Re: [Rxtx] Killing RXTX My goal is to allow a user to safely disconnect a device while the application is running and then allow them to plug it back in and reconnect. Currently, I am shutting down the thread with: serial.close(); where serial is an instance of SerialPort. When I do this, I am getting the invalid memory access error. "Invalid memory access of location 0x12b2f6938 rip=0x128f3d12f". Am I closing the connection correctly or is there a different way? If I am closing it properly and this is a bug, is there a workaround? Thanks, Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com On Tue, Sep 7, 2010 at 6:36 PM, Adrian Crum wrote: According to the javax.comm API, calling removeEventListener() is not necessary, because the close method does that. What do you mean when you say it breaks? -Adrian --- On Tue, 9/7/10, Breznak, Robert wrote: From: Breznak, Robert Subject: [Rxtx] Killing RXTX To: rxtx at qbang.org Date: Tuesday, September 7, 2010, 11:06 AM Maybe I am totally missing something here, so please let me know if I am. I have an application that uses RXTX and I'd like to kill the RXTX eventLoop so there is a full disconnect. When I use : serial.removeEventListener(); serial.close(); it breaks in linux or on a 64 bit machine / VM. Is there a better / correct way to kill the thread? Bob ------------------- Bob Breznak 1-877-474-6038 ext#701 www.neuronrobotics.com -----Inline Attachment Follows----- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adrian.crum at yahoo.com Sun Sep 12 11:11:43 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Sun, 12 Sep 2010 10:11:43 -0700 (PDT) Subject: [Rxtx] RXTX Rewrite Message-ID: <915801.14318.qm@web63102.mail.re1.yahoo.com> I have committed the preliminary code for the rewrite I have been working on. And I stress *preliminary* - because there is a lot of work yet to be done. Check out the current repo using these instructions: http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code and you will find the rewrite in the Rewrite2010 folder. There is a pdf document in that folder that gives an overview of the rewrite. There are some folders mentioned in the pdf document that aren't in the repo because CVS didn't accept some of the empty folders. None of the rewrite code is set in stone - feel free to make comments, suggestions, and supply patches. If there is any interest in it, then I will make a commitment to review and commit patches. -Adrian From Noel.Goldsmith at dsto.defence.gov.au Sun Sep 12 17:58:46 2010 From: Noel.Goldsmith at dsto.defence.gov.au (Goldsmith, Noel) Date: Mon, 13 Sep 2010 09:58:46 +1000 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Message-ID: Mariusz, and the list. Hi, Sorry to bother you. I am a bit confused by the state of RXTX and the code on CVS etc. I am running a version (?) of RXTX successfully on G5 and Intel Macs in the lab, and am mostly very happy. Although there is a problem with 64 bit ImageJ and RXTX, it dies when the use of the serial port is invoked. So I have restricted use to ImageJ32 when using automation via the serial port. So if the code has been improved I would like to try that as well. I am writing a quality manual for the operation of the equipment in the lab which will include items such as "Installing a new computer, installing hardware (USB-Serial converters), installing software (drivers and RXTX, ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list of what to do, where to put things and where to get them if you have lost the links, install CD's or whatever. As RXTX is an open source code, I would like to include the source code for the version I have running. This is dated 13 November 2008, and I believe includes Mariusz's corrections for the connect-disconnect problem. This version certainly overcomes the problems of having to add a user for each new account on the Mac. This part works well. At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another software package we use does not behave properly, not an RXTX problem). I can download the CVS code, but before I do that would like to know that it will be a useful exercise. Thank you for your time, and also for being involved in producing a piece of complex code, which fills a niche and is certainly useful. Noel Noel Goldsmith Air Vehicles Division DSTO 506 Lorimer Street Port Melbourne 3207 Victoria AUSTRALIA 613 96267527 0428364003 noel.goldsmith at dsto.defence.gov.au Because I am behind a solid firewall, it may be better to send large attachments to ngoldsmi at bigpond.net.au -- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From george.dma at gmail.com Sun Sep 12 18:11:27 2010 From: george.dma at gmail.com (George H) Date: Mon, 13 Sep 2010 03:11:27 +0300 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: On Mon, Sep 13, 2010 at 2:58 AM, Goldsmith, Noel wrote: > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on ?four G5 and ?four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ?ngoldsmi at bigpond.net.au Hello, Just wondering, is the question what is the current state of the CVS or state of the project or distribution of the source according to license or about the 64bit imageJ problem you are having. For starters the current state of the CVS is that it is undergoing a re-write spearheaded by adrian crum and any other persons wishing to participate in it. The project was dormant for a while but currently is getting quite a few patches in. Great to see this lib is being used by many organizations :) -- George H george.dma at gmail.com From johnco3 at gmail.com Sun Sep 12 20:02:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Sun, 12 Sep 2010 22:02:26 -0400 Subject: [Rxtx] RXTX Rewrite In-Reply-To: <915801.14318.qm@web63102.mail.re1.yahoo.com> References: <915801.14318.qm@web63102.mail.re1.yahoo.com> Message-ID: Adrian, nice job updating the repo, by the way, although I am not using the rewrite version yet, I did a build of the latest/greatest gnu.io branch and it looks pretty good (not sure if you also patched that). I include here some patches I've been keeping an eye on for the UART disconnect functionality submitted by another developer, and it looks like at least so far with the updated repo and my attached suggested patches things are working pretty well. I suspect that the thing that made the biggest difference was making the java monitor thread a daemon (using setDaemon(true) made the biggest difference as I am no longer - at least so far) seeing some of the lockups I used to see) I merged in my changes and than ran cvs diff -u . > suggestions.patch to create the patch file. All the best John Coffey Index: src/SerialImp.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.c,v retrieving revision 1.46.2.209 diff --brief -r1.46.2.209 SerialImp.c Files /tmp/cvsiRJuXn and SerialImp.c differ Index: src/SerialImp.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/SerialImp.h,v retrieving revision 1.11.2.57 diff --brief -r1.11.2.57 SerialImp.h Files /tmp/cvs6YOPIL and SerialImp.h differ Index: src/termios.c =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/termios.c,v retrieving revision 1.9.2.65 diff --brief -r1.9.2.65 termios.c Files /tmp/cvs9htyw9 and termios.c differ Index: src/win32termios.h =================================================================== RCS file: /var/cvs/cvsroot/rxtx-devel/src/win32termios.h,v retrieving revision 1.5.2.36 diff --brief -r1.5.2.36 win32termios.h On Sun, Sep 12, 2010 at 1:11 PM, Adrian Crum wrote: > I have committed the preliminary code for the rewrite I have been working > on. And I stress *preliminary* - because there is a lot of work yet to be > done. > > Check out the current repo using these instructions: > > http://rxtx.qbang.org/wiki/index.php/Retrieving_Source_Code > > and you will find the rewrite in the Rewrite2010 folder. There is a pdf > document in that folder that gives an overview of the rewrite. > > There are some folders mentioned in the pdf document that aren't in the > repo because CVS didn't accept some of the empty folders. > > None of the rewrite code is set in stone - feel free to make comments, > suggestions, and supply patches. > > If there is any interest in it, then I will make a commitment to review and > commit patches. > > -Adrian > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: suggestions.patch Type: application/octet-stream Size: 10544 bytes Desc: not available URL: From mariusz.dec at gmail.com Sun Sep 12 23:19:46 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Mon, 13 Sep 2010 07:19:46 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: Hi Noell, Hi all, I am not a developer of the RXTX :(. Additionally, I am not able to do extensive tests of the RXTX on many platforms. I have had a challenge with serial communication and Java and I did a solution which works. I have received some e-mails with "Thank you" and it says that my solution works in many cases. If you wish - I have a copy of RXTX sources from November '2009. !!!!! IMPORTANT ABOUT MY WORKS !!!!! 1. There is NO corrections in RXTX code. 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't remember date and what exactly.. 3. Close/reopen/disconnect USB problems are to solve in application's Java code only - this is it, what I did. In my opinion it should work in most cases, only problematic may be quality of VCP USB drivers... I am using FTDI solutions only. Regards Mariusz ----- Original Message ----- From: "Goldsmith, Noel" To: ; ; "Giuliano Gavazzi" Sent: Monday, September 13, 2010 1:58 AM Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > Mariusz, and the list. > Hi, > Sorry to bother you. > I am a bit confused by the state of RXTX and the code on CVS etc. > I am running a version (?) of RXTX successfully on G5 and Intel Macs in the > lab, and am mostly very happy. > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > use of the serial port is invoked. So I have restricted use to ImageJ32 when > using automation via the serial port. So if the code has been improved I > would like to try that as well. > > I am writing a quality manual for the operation of the equipment in the lab > which will include items such as "Installing a new computer, installing > hardware (USB-Serial converters), installing software (drivers and RXTX, > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full list > of what to do, where to put things and where to get them if you have lost > the links, install CD's or whatever. > > As RXTX is an open source code, I would like to include the source code for > the version I have running. This is dated 13 November 2008, and I believe > includes Mariusz's corrections for the connect-disconnect problem. This > version certainly overcomes the problems of having to add a user for each > new account on the Mac. This part works well. > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but another > software package we use does not behave properly, not an RXTX problem). > > I can download the CVS code, but before I do that would like to know that it > will be a useful exercise. > > Thank you for your time, and also for being involved in producing a piece of > complex code, which fills a niche and is certainly useful. > Noel > > Noel Goldsmith > Air Vehicles Division > DSTO > 506 Lorimer Street > Port Melbourne > 3207 Victoria > AUSTRALIA > 613 96267527 > 0428364003 > noel.goldsmith at dsto.defence.gov.au > > Because I am behind a solid firewall, it may be better to send large > attachments to > > ngoldsmi at bigpond.net.au > > -- > > > > > IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. > From johnco3 at gmail.com Mon Sep 13 17:17:07 2010 From: johnco3 at gmail.com (John Coffey) Date: Mon, 13 Sep 2010 19:17:07 -0400 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: Mariusz, I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. Anyways, I spent the greater part of today and last night merging your fixes with the latest build - fixes that Adrian Crum has been tweaking (I'm not using the code yet however), I'm just concentrating on the RXTXpre2.2 code). Later tonight I should be able to share the patches if anyone's interested. So far, it's working on Windows 7x86, later tonight, I should be able to get the Windows 7 x64 tested. One observation that I found to be really helpful in merging the latest code against your fixes was that there are several setDaemon(true) calls in the latest code which seems to add to the stability - I previously used to get several system hangs without that change. John Coffey On Mon, Sep 13, 2010 at 1:19 AM, M.Dec-GM wrote: > Hi Noell, > Hi all, > I am not a developer of the RXTX :(. > Additionally, I am not able to do extensive tests of the RXTX on many > platforms. > I have had a challenge with serial communication and Java and I did a > solution which works. > I have received some e-mails with "Thank you" and it says that my solution > works in many cases. > If you wish - I have a copy of RXTX sources from November '2009. > > !!!!! IMPORTANT ABOUT MY WORKS !!!!! > 1. There is NO corrections in RXTX code. > 2. I am using RXTX2.2pre2 probably with minor CVS changes - sorry I don't > remember date and what exactly.. > 3. Close/reopen/disconnect USB problems are to solve in application's Java > code only - this is it, what I did. > > In my opinion it should work in most cases, only problematic may be quality > of VCP USB drivers... > I am using FTDI solutions only. > > Regards > Mariusz > > > ----- Original Message ----- > From: "Goldsmith, Noel" > To: ; ; "Giuliano Gavazzi" < > dev+lists at humph.com > > Sent: Monday, September 13, 2010 1:58 AM > Subject: RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] > > > > Mariusz, and the list. > > Hi, > > Sorry to bother you. > > I am a bit confused by the state of RXTX and the code on CVS etc. > > I am running a version (?) of RXTX successfully on G5 and Intel Macs in > the > > lab, and am mostly very happy. > > Although there is a problem with 64 bit ImageJ and RXTX, it dies when the > > use of the serial port is invoked. So I have restricted use to ImageJ32 > when > > using automation via the serial port. So if the code has been improved I > > would like to try that as well. > > > > I am writing a quality manual for the operation of the equipment in the > lab > > which will include items such as "Installing a new computer, installing > > hardware (USB-Serial converters), installing software (drivers and RXTX, > > ImageJ, Diagnostic Instruments Camera Software etc). Basically the full > list > > of what to do, where to put things and where to get them if you have lost > > the links, install CD's or whatever. > > > > As RXTX is an open source code, I would like to include the source code > for > > the version I have running. This is dated 13 November 2008, and I believe > > includes Mariusz's corrections for the connect-disconnect problem. This > > version certainly overcomes the problems of having to add a user for each > > new account on the Mac. This part works well. > > > > At the moment I am running OSX 10.5.8 on four G5 and four Intel Macs. > > > > (I have trialed the same libraries on 10.6.x and RXTX seems ok ( but > another > > software package we use does not behave properly, not an RXTX problem). > > > > I can download the CVS code, but before I do that would like to know that > it > > will be a useful exercise. > > > > Thank you for your time, and also for being involved in producing a piece > of > > complex code, which fills a niche and is certainly useful. > > Noel > > > > Noel Goldsmith > > Air Vehicles Division > > DSTO > > 506 Lorimer Street > > Port Melbourne > > 3207 Victoria > > AUSTRALIA > > 613 96267527 > > 0428364003 > > noel.goldsmith at dsto.defence.gov.au > > > > Because I am behind a solid firewall, it may be better to send large > > attachments to > > > > ngoldsmi at bigpond.net.au > > > > -- > > > > > > > > > > IMPORTANT: This email remains the property of the Department of Defence > and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If > you have received this email in error, you are requested to contact the > sender and delete the email. > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Mon Sep 13 18:08:50 2010 From: bschlining at gmail.com (Brian Schlining) Date: Mon, 13 Sep 2010 17:08:50 -0700 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] In-Reply-To: References: Message-ID: I recall the elegant fix you put together to handle Close/reopen/disconnect > USB patch? As I recall the only downside from general adoption by the rxtx > community was that the signature of some methods had an extra exception > which was not quite compatible with javax.comm or something to that effect. > I can certainly live with that :) given the benefits of your fixes. > I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Sep 13 23:04:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 07:04:58 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: Message-ID: <40FAD90D582845149A7EF8024FF58480@mdam2> Hi John, Hi Brian, Hi All I have send a parts of application with this code - (it isn't RXTX patch) to coulple of peples. But now there is more questions... We have a new day now - 7:00 am. I will busy until 10 am. After that I will prepare clear example and I will publish it here. Regards Mariusz ----- Original Message ----- From: Brian Schlining To: rxtx at qbang.org Sent: Tuesday, September 14, 2010 2:08 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] I recall the elegant fix you put together to handle Close/reopen/disconnect USB patch? As I recall the only downside from general adoption by the rxtx community was that the signature of some methods had an extra exception which was not quite compatible with javax.comm or something to that effect. I can certainly live with that :) given the benefits of your fixes. I haven't looked at the code in question, but if the only downside is a change to the method signature I would recommend the following, if you want wider adoption: 1) If it's a new checked exception that's being thrown (i.e a subclass of Exception), change the exception to an unchecked (i.e. a subclass of RuntimeException). 2) Document in the javadoc that the method can throw your special Exception. 3) Return the method signature to match what RXTX had. The method can still throw your exception but it doesn't force users to catch it like a checked Exception does. Just my 2 cents -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 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 mariusz.dec at gmail.com Tue Sep 14 01:36:11 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Tue, 14 Sep 2010 09:36:11 +0200 Subject: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] References: <40FAD90D582845149A7EF8024FF58480@mdam2> Message-ID: Thank you John :) I have just prepared Java workaround example app with documentation inside, and in few minutes it will available here as well. I think that your solution is good, but in my example I am showing aditionally a very fast method of the transferring data from serial to application. It was suggestion of Michael Erskine and I did it. So I will publish it as well :) Regards Mariusz ----- Original Message ----- From: "John Coffey" To: Sent: Tuesday, September 14, 2010 8:24 AM Subject: Re: [Rxtx] RXTX and Macintosh, Information Please [SEC=UNCLASSIFIED] Mariusz, here is a patch that I've been testing this evening so far without problems (I tested Windows XP 32 bit earlier and here I just finished testing a recompiled set of DLLs on x64 (compiled as x64), My code is against the head of the current build and includes the disconnect patch and a single patch that I needed for an 8200 byte input buffer that I needed for my app. My patch is basically a combination of the patch below brought up to date with the head of the 2.2pre2 tree in CVS and a separate as per the link below you will need to include Ilkkya's separate files are included via the link below. My patch was generated by cvs diff -up . > latestgreatest.patch so the patch can be applied src/gnu/io/PortAlreadyClosedException.java src/gnu/io/SerialReconnectDemo.java It is in 'cvs diff -up' format. It can be applied with 'patch -p0 < latestgreatest.patch' in rxtx-devel directory I added one thing that I needed for myself (for SetupComm to have an 8k buffer for an avionics protocol, without it my app hung and unfortunately the APIs to set the input and output buffer size for the communications port are no-ops (see my commented out app code below)! If you could see your way to putting that function in I would be really grateful http://mailman.qbang.org/pipermail/rxtx/2009-September/5724682.html /** internal thread control logic */ private void doCommControl(final Command aCommand) throws IOException { try { switch (aCommand) { case StartComms: mSerialPort = (SerialPort) mPortId.open("SerialMonitor", 2000); // @TODO: Try to add support for buffer size // This currently does not work as the port size // parameter is ignored // mSerialPort.setInputBufferSize(8200); // int inputBufferSize = mSerialPort.getInputBufferSize(); // mSerialPort.setOutputBufferSize(8200); // int outputBufferSize = mSerialPort.getOutputBufferSize(); // pre fetch from the receive buffer //mSerialPort.enableReceiveThreshold(4096); if (mFlowControl == FlowControl.FlowCtsRts) { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_RTSCTS_IN | SerialPort.FLOWCONTROL_RTSCTS_OUT); } else { mSerialPort.setFlowControlMode( SerialPort.FLOWCONTROL_NONE); } mInputStream = mSerialPort.getInputStream(); mOutputStream = mSerialPort.getOutputStream(); mSerialPort.addEventListener(this); On Tue, Sep 14, 2010 at 1:04 AM, M.Dec-GM wrote: > Hi John, Hi Brian, Hi All > > I have send a parts of application with this code - (it isn't RXTX patch) to > coulple of peples. > But now there is more questions... > We have a new day now - 7:00 am. I will busy until 10 am. > After that I will prepare clear example and I will publish it here. > Regards > Mariusz > > > ----- Original Message ----- > From: Brian Schlining > To: rxtx at qbang.org > Sent: Tuesday, September 14, 2010 2:08 AM > Subject: Re: [Rxtx] RXTX and Macintosh, Information Please > [SEC=UNCLASSIFIED] > > >> I recall the elegant fix you put together to >> handle Close/reopen/disconnect USB patch? As I recall the only downside >> from general adoption by the rxtx community was that the signature of some >> methods had an extra exception which was not quite compatible with >> javax.comm or something to that effect. I can certainly live with that :) >> given the benefits of your fixes. > > I haven't looked at the code in question, but if the only downside is a > change to the method signature I would recommend the following, if you want > wider adoption: > 1) If it's a new checked exception that's being thrown (i.e a subclass of > Exception), change the exception to an unchecked (i.e. a subclass of > RuntimeException). > 2) Document in the javadoc that the method can throw your special Exception. > 3) Return the method signature to match what RXTX had. The method can still > throw your exception but it doesn't force users to catch it like a checked > Exception does. > Just my 2 cents > -- > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > Brian Schlining > bschlining at gmail.com > > ________________________________ > > _______________________________________________ > 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 mariusz.dec at gmail.com Tue Sep 14 01:46:41 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Tue, 14 Sep 2010 09:46:41 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app Message-ID: Hi all, Very long post beacause of attachments problems - some peoples said me that my attachment with previuos version was unreadable, so I have decided to put everything in mail body. What is here? 1. File: RXTXSerialExample.java 2. File: SerialBufException.java 3. Console printout while program was working and USB was disconnected twice in the loop (10 runs). Notices: 1. I would like to say, that it wasn't tested by me in many environments because of small number of users of my application yet :), but currently it works on W7, XP, Vista and Mac. I don't know which MacOS version - sorry. 2. I have mentioned many times that I am using FTDI USB VCP drivers and hardware ONLY. This is possible that other VCP drivers will not work so friendly or not in all OS-es. So - enjoy and try :) Mariusz //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // By Mariusz Dec, Poland // November 2009 - September 2010 // // Main goals: // Prevents USB disconneting // Fastest available method of data transfer to application // Needs file SerialBufException.java as an Exception service // // Tested on: // RXTX2.2pre2 // Windows XP Pro SP3 // Windows Vista Home Basic // Ubuntu, Kernel 2.6.28-16-generic //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& import gnu.io.CommPort; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; public class RXTXSerialExample { public static CommPort commPort; public static InputStream inStream; public static OutputStream outStream; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Set of variables to external control of the RXTXserial state private static final Object stopReadMutex = new Object(); private static final Object stopWriteMutex = new Object(); public static boolean stopRead = false; public static boolean stopWrite = false; //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public static RXTXSerialExample.SerialWriter serialCommWr = null; public static RXTXSerialExample serialConnector = null; static int bufSize = 1000; public static int bufIdx = 0; public static byte[] inBuffer; // Info for main loop about problem with close - here for proper display only public static int closeOk =0; public RXTXSerialExample() { super(); } //****************************************************************************** void disConnect ( String portName ) throws Exception { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // preparing inStream and outStream to deactivate before close // Synchronized because SerialReader and SerialWriter are Threads synchronized(stopReadMutex) {stopRead = true;} synchronized(stopWriteMutex) {stopWrite = true;} inStream.close(); outStream.close(); commPort.close(); } //****************************************************************************** void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { commPort = portIdentifier.open(this.getClass().getName(),2000); if ( commPort instanceof SerialPort ) { SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Critical configuration stuff // rawImp.c read_byte_array, line 840, 861 // Windows COM without received data returns if no data available. // Linux /dev/ttyXXX wait in endless loop when no data, so ReceiveTimeout should be configured // It works in Windows as well // What about Mac - my brother has tested it and were no bad comments :) commPort.enableReceiveTimeout(10); //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& inStream = serialPort.getInputStream(); outStream = serialPort.getOutputStream(); serialCommWr = new SerialWriter(outStream); (new Thread(new SerialReader(inStream))).start(); (new Thread(serialCommWr)).start(); } else { System.out.println("Error: Only serial ports are handled by this example."); } } } //****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** /** */ public static class SerialWriter implements Runnable { OutputStream out; public SerialWriter ( OutputStream out ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the outStream synchronized(stopWriteMutex) {stopWrite = false;} this.out = out; } public void run () { try { int c = 0; while ( ( c = System.in.read()) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close // In this example not needed but necessary when other threads would like to write to this port if (stopWrite) { System.out.println("Stopped writing..."); break; } this.out.write(c); } } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } //****************************************************************************** public void sendChar (byte sch) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Test purpose // If Rx is connected to Tx (DB9 - pin 2 connected to 3) data will return to inStream as @ABCDEF... in test loop try { out.write(sch); } catch ( IOException e ) { closeOk = 1; e.printStackTrace(); } } } //****************************************************************************** //****************************************************************************** //****************************************************************************** public static void main ( String[] args ) { // Hard coded ports, but list of the available ports works good... // Windows String portName = "COM17"; // Linux // String portName = "/dev/ttyUSB0"; // Mac //String portName = "/dev/tty????????"; try { serialConnector = new RXTXSerialExample(); } catch ( Exception e ) { e.printStackTrace(); System.exit(1); } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Memory test purpose - checking if variable configuration doesn't waste heap System.out.println("Memory used on start: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.out.println("--------------"); inBuffer = new byte[bufSize]; System.out.println("Trying open()..." + portName); for (int i =0 ; i <10;i++) { closeOk = 0; try { serialConnector.connect(portName); System.out.println("Successfully opened "+portName+": #"+i); } catch (Exception e) { System.out.println("Not opened, not available ??? - but app still works...\n"+e.toString()); closeOk = 1; } System.out.println("Sending ASCII code: " +(i +64)); serialCommWr.sendChar((byte) (i+64)); System.out.println("Waiting..."); try{ Thread.sleep(3000); } catch (Exception e) { System.out.println(e.toString()); closeOk = 1; } System.out.println("Trying close()..."); try { serialConnector.disConnect(portName); } catch (Exception e) { e.printStackTrace(); closeOk = 1; } if (closeOk ==0) { System.out.println("Successfully closed: #"+i); System.out.println("--------------"); } else { System.out.println("!!!!!! Error while closing or whatever and whereever: #"+i); System.out.println("--------------"); } } System.gc(); System.out.println("Memory used on finish: "+ (Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())); System.exit(0); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: RXTXSerialExample.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // How to use RXTXSerialPort // // By Mariusz Dec, Poland // November 2009 - September 2010 // // This file: // SerialBufException.java as an Exception service // Main goal: // Fastest available method of data transfer to application // //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& public class SerialBufException extends Exception{ public SerialBufException(int bufIdx) { System.out.println("----->>>> Serial Exception thrown, current index of buffer: " + bufIdx); // Here comes call to method in main application // MainApplication_Serial_Service_method(bufIdx); } } //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // END OF FILE: SerialBufException.java //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Below is the printout of the console while program was running. I have disconnected USB twice during the loop. Error messages from termios.c come asynchronously, so place between program's messages is random. "Odmowa dost?pu." means "Access denied." "Nie mo?na odnale?? okre?lonego pliku." means: "File not found" run: Memory used on start: 218864 -------------- Trying open()...COM17 Successfully opened COM17: #0 Sending ASCII code: 64 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 1 Trying close()... Stopped reading... Successfully closed: #0 -------------- Successfully opened COM17: #1 Sending ASCII code: 65 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 2 Trying close()... Stopped reading... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. .... MD: Many, many times .... Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Successfully closed: #1 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 66 Waiting... Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. Trying close()... !!!!!! Error while closing or whatever and whereever: #2 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 67 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #3 -------------- Successfully opened COM17: #4 Sending ASCII code: 68 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 3 Trying close()... Stopped reading... Successfully closed: #4 -------------- Successfully opened COM17: #5 Sending ASCII code: 69 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 4 java.io.IOException: No error in readArray at gnu.io.RXTXPort.readArray(Native Method) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1460) at gnu.io.RXTXPort$SerialInputStream.read(RXTXPort.java:1345) at RXTXSerialExample$SerialReader.run(RXTXSerialExample.java:161) at java.lang.Thread.run(Thread.java:619) Error 0x5 at ../src/termios.c(517): Odmowa dost?pu. Error 0x5 at ../src/termios.c(2712): Odmowa dost?pu. ..................... MD: Many times this set of messages above and only two times messages below: ............ Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Error 0x2 at ../src/termios.c(892): Nie mo?na odnale?? okre?lonego pliku. Trying close()... !!!!!! Error while closing or whatever and whereever: #5 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 70 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #6 -------------- Not opened, not available ??? - but app still works... gnu.io.PortInUseException: Unknown Application Sending ASCII code: 71 Waiting... Trying close()... !!!!!! Error while closing or whatever and whereever: #7 -------------- Successfully opened COM17: #8 Sending ASCII code: 72 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 5 Trying close()... Stopped reading... Successfully closed: #8 -------------- Successfully opened COM17: #9 Sending ASCII code: 73 Waiting... ----->>>> Serial Exception thrown, current index of buffer: 6 Trying close()... Stopped reading... Successfully closed: #9 -------------- Memory used on finish: 137080 BUILD SUCCESSFUL (total time: 37 seconds) From HowardZ at howardz.com Tue Sep 14 14:10:24 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Tue, 14 Sep 2010 16:10:24 -0400 Subject: [Rxtx] JNA In-Reply-To: References: Message-ID: <4C8FD6B0.9070306@howardz.com> Hi everyone, I have been playing with jna. The only downside I can see from using jna is that it makes RXTX dependent on the jna package. So, if someday jna is no longer supported, we need to support it - assuming it is open source. Yesterday I downloaded jna.jar and platform.jar from https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 jna.jar does the work and has built into it libraries for all the operating systems. platform.jar has (I think) all the win32 api calls defined for easy access from java. I modified all my code to use the jna/platform method to access the MS Windows registry (instead of Winregistry). None of my programs write to the registry, as I try to keep things platform independent. But I sometimes need to read the registry to interface to some software which only runs on MS Windows and uses the registry. It seems to work well. BTW, pretty much the only think I have changed in RXTX is to eliminate the checking for valid COM ports every time a program that uses RXTX is started. I hate how it raises RTS on all my com ports, as this causes my Amateur Radio to start transmitting. So, only for MS Windows, I modified RXTX to read the registry to get a list of all the valid COM ports. Here are some code snipets from my modified RXTXComDriver.java // Begin of added by Howard Zuckerman import com.sun.jna.*; // JNA to call native operating system libraries import com.sun.jna.win32.*; import com.sun.jna.platform.win32.*; import com.sun.jna.platform.win32.WinReg; import com.sun.jna.platform.win32.Advapi32Util; import java.util.Comparator; // End of added by Howard Zuckerman . . . //Begin Added/Modified by Howard Zuckerman String[] h = null; if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, Vista, XP, etc.. // For MS Windows, all valid COM ports are determined at boot time // and all the valid COM ports are listed in the registry. Boolean registryError = false; TreeMap tm = new TreeMap(); try { tm = Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, "HARDWARE\\DEVICEMAP\\SERIALCOMM"); } catch(Exception e) { registryError = true; System.out.println("RXTXCommDriver: Error reading JNA registry COM port values"); } if (!registryError) { System.out.println("RXTXCommDriver: Number of COM Ports = " + tm.size()); if (tm.size() < 1) registryError = true; } if (!registryError) { int len = tm.size(); h = new String[len]; for (int i=0; i < len; i++) { h[i] = (String) tm.firstEntry().getValue(); h[i] = h[i].trim(); System.out.println("COM port #"+i+"='"+h[i]+"'"); tm.remove(tm.firstEntry().getKey()); } } else { // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; } // Sort the COM port names first by length and // then alphabetically without regards to upper/lower case StringLengthComparator byStringLength = new StringLengthComparator(); Arrays.sort(h, byStringLength ); //System.out.print("TwoWaySerialComm - com list = "); for(int i=0; i { // Comparator interface requires defining compare method. public int compare(String a, String b) { int comp = a.length() - b.length(); if (comp != 0) { //... If different lengths, we're done. return comp; } else { //... If equal lengths, sort alphabetically. return a.toLowerCase().compareTo( b.toLowerCase() ); } } } // End added/modified by Howard Zuckerman . . . private void addSpecifiedPorts(String names, int PortType) { final String pathSep = System.getProperty("path.separator", ":"); final StringTokenizer tok = new StringTokenizer(names, pathSep); if (debug) System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); while (tok.hasMoreElements()) { String PortName = tok.nextToken(); // Commented out by Howard Zuckerman if (testRead(PortName, PortType)) CommPortIdentifier.addPortName(PortName, PortType, this); } } From hontvari at flyordie.com Tue Sep 14 21:27:33 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Wed, 15 Sep 2010 05:27:33 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup Message-ID: <4C903D25.5030301@flyordie.com> I want to start a data connection through a mobile phone, acting as a modem, using AT commands. It does work in a terminal as expected. There is a strange behavior when I do the same thing through RXTX. The modem should respond to the dial (ATD...) command with a CONNECT ... message, after it successfully connected to the remote modem. It does respond. But my code receive this message and any data the remote modem sends only after the data transfer is completed and the modems disconnects or after the modem temporarily goes into command state during the session. There is a log below and I attached the test class which produced it. For the record: The phone is Siemens C55 connected through an USB-Serial converter data cable, the OS is Windows 7 - 32 bit. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 377 Flow control: 0 1379 Event: Output buffer is empty (false->true) 1380 Sent: atd+36304696729\r 1381 Event: Output buffer is empty (false->true) 1428 Event: Data available (false->true) 1528 Read: atd+36304696729\r 20758 Event: Carrier detect (false->true) 22800 Event: Output buffer is empty (false->true) 22800 Sent: Hello World!\r\n 22801 Event: Output buffer is empty (false->true) 22801 Sent: Lets go chat!\r\n 22805 Event: Output buffer is empty (false->true) 32802 Event: Output buffer is empty (false->true) 32802 Sent: +++ 32803 Event: Output buffer is empty (false->true) 33808 Event: Data available (false->true) 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! \r\r\nOK\r\n 35803 Event: Output buffer is empty (false->true) 35803 Sent: ath\r 35805 Event: Output buffer is empty (false->true) 35860 Event: Data available (false->true) 35962 Read: ath\r 36266 Event: Data available (false->true) 36367 Read: \r\nOK\r\n 36368 Event: Carrier detect (true->false) 37803 The End -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Test.java URL: From mariusz.dec at gmail.com Tue Sep 14 23:48:33 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 07:48:33 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> Message-ID: <95E46F3E54BF4D77935D0B034703389C@mdam2> Hi all, ----- Original Message ----- From: To: Sent: Tuesday, September 14, 2010 10:10 PM Subject: [Rxtx] JNA > Hi everyone, > > I have been playing with jna. At first most important thing: Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... And, sorry, this looks strictly as a play only... We are talking: "Art for the Art:. Facts: I don't understand what for doing Java application platform dependend in this part of RXTX??? Obtaining port list in RXTX works good, and is very easy to change... Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. So - this:part looks crazy: // In case of errors, list COM1 through COM9 - it is better than nothing. h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... Please try to connect to the port from this list.... "Better than nothing" is to write - No ports, List Error or something like that... No comments more... Mariusz } From mariusz.dec at gmail.com Wed Sep 15 01:06:53 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 09:06:53 +0200 Subject: [Rxtx] RXTX - USB disconnecting safe and fast data transfer to app References: Message-ID: Hi all, I did example from previous post very fast, using parts of another applications. And therefore there is one (currently known) place for "tuning" yet :) Below complete, updated method SerialReader. If we want to stop thread from outside or USB problem occurs, we should check if thread is about to stop before reading EACH byte from "buffer". Sequence: if (stopRead) { System.out.println("Stopped reading..."); break; } Should be inside reading loop (len>0) as well, before access to "buffer". This problem may be important when packets are long. Sorry, Mariusz ****************************************************************************** /** */ public static class SerialReader implements Runnable { private static InputStream in; public SerialReader ( InputStream inStrm ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Enabling work of the inStream synchronized(stopReadMutex) {stopRead = false;} this.in = inStrm; } public void run () { byte[] buffer = new byte[1024]; int len = -1; try { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Here is endless loop with synchronized exit; // Inside the loop we have incoming data. while ( ( len = this.in.read(buffer)) > -1 ) { //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Mariusz Dec //&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& // Checking if about to close if (stopRead) { System.out.println("Stopped reading..."); break; } if (len>0){ for (int ix=0; ix= bufSize) {bufIdx = 0;} } // After emptying buffer we are transferring info about it... // This is the fastest method of the application reaction on incoming data. // // Exception is throwing // In this example current buffer index is transferred // Main application should remember last utilized index and read data between indexes. // Remember that in this example bufIdx is the first FREE buffer index try{throw new SerialBufException(bufIdx);} catch (Exception e){} } } } catch ( IOException e ) { // Mariusz Dec // Code below looks interesting, but I don't remember why it looks so (I did it almost one year ago). // Probably this is needed when USB disconnecting occurs while specific actions of the RXTX. // Sorry, but there is only few lines :) closeOk = 1; e.printStackTrace(); try{ SerialReader.in.close(); commPort.close(); Thread.currentThread().interrupt(); } catch (Exception ex) { closeOk = 1; System.out.println("Exception closing port in SerialReader: " + ex.toString()); } } } } //****************************************************************************** From george.dma at gmail.com Wed Sep 15 01:28:13 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 10:28:13 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C8FD6B0.9070306@howardz.com> References: <4C8FD6B0.9070306@howardz.com> Message-ID: On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com wrote: > ?Hi everyone, > > I have been playing with jna. ?The only downside I can see from using jna is > that it makes RXTX dependent on the jna package. ?So, if someday jna is no > longer supported, we need to support it - assuming it is open source. > > Yesterday I downloaded jna.jar and platform.jar from > https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 > > jna.jar does the work and has built into it libraries for all the operating > systems. > > platform.jar has (I think) all the win32 api calls defined for easy access > from java. > > I modified all my code to use the jna/platform method to access the MS > Windows registry (instead of Winregistry). ?None of my programs write to the > registry, as I try to keep things platform independent. ?But I sometimes > need to read the registry to interface to some software which only runs on > MS Windows and uses the registry. ?It seems to work well. > > BTW, pretty much the only think I have changed in RXTX is to eliminate the > checking for valid COM ports every time a program that uses RXTX is started. > ?I hate how it raises RTS on all my com ports, as this causes my Amateur > Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to > read the registry to get a list of all the valid COM ports. > > Here are some code snipets from my modified RXTXComDriver.java > > // Begin of added by Howard Zuckerman > import com.sun.jna.*; ? ? ? // JNA to call native operating system libraries > import com.sun.jna.win32.*; > import com.sun.jna.platform.win32.*; > import com.sun.jna.platform.win32.WinReg; > import com.sun.jna.platform.win32.Advapi32Util; > import java.util.Comparator; > // End of added by Howard Zuckerman > . > . > . > //Begin Added/Modified by Howard Zuckerman > ? ? ? ? ? ?String[] h = null; > ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, > Vista, XP, etc.. > ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at boot > time > ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. > ? ? ? ? ? ? ? ?Boolean registryError = false; > ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); > ? ? ? ? ? ? ? ?try { > ? ? ? ? ? ? ? ? ? ?tm = > Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, > ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); > ? ? ? ? ? ? ? ?} catch(Exception e) { > ? ? ? ? ? ? ? ? ? ?registryError = true; > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA > registry COM port values"); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM Ports = > " + tm.size()); > ? ? ? ? ? ? ? ? ? ?if (tm.size() < 1) registryError = true; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?if (!registryError) { > ? ? ? ? ? ? ? ? ? ?int len = tm.size(); > ? ? ? ? ? ? ? ? ? ?h = new String[len]; > ? ? ? ? ? ? ? ? ? ?for (int i=0; i < len; i++) { > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); > ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); > ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); > ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); > ? ? ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - it > is better than nothing. > ? ? ? ? ? ? ? ? ? ?h = new String[] > {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?// Sort the COM port names first by length and > ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case > ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); > ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); > ? ? ? ? ? ? ? ?for(int i=0; i ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); > ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], CommPortIdentifier.PORT_SERIAL); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ? ? ?//System.out.println(""); > > > ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. > computer > > ? ? ? ? ? ? ? ?/* > ? ? ? ? ? ? ? ?First try to register ports specified in the properties > ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. > ? ? ? ? ? ? ? ?*/ > ? ? ? ?for (int > PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) > { > ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { > ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { > ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > ? ? ? ? ? ?} > ? ?} > > ? ? ? ?// The following class is for use for sorting Strings where > ? ? ? ?// we want shorter Strings first before longer Strings. > ? ? ? ?// Strings of the same length are sorted alphabetically > ? ? ? ?// without regard to upper or lower case. > ? ? ? ?// Example use: > ? ? ? ?// h = new String[] > {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; > ? ? ? ?// StringLengthComparator byStringLength = new > StringLengthComparator(); > ? ? ? ?// Arrays.sort(h, byStringLength ); > ? ? ? ?class StringLengthComparator implements Comparator { > ? ? ? ? ? ?// Comparator interface requires defining compare method. > ? ? ? ? ? ?public int compare(String a, String b) { > ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); > ? ? ? ? ? ? ? ?if (comp != 0) { > ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. > ? ? ? ? ? ? ? ? ? ?return comp; > ? ? ? ? ? ? ? ?} else { > ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. > ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); > ? ? ? ? ? ? ? ?} > ? ? ? ? ? ?} > ? ? ? ?} > // End added/modified by Howard Zuckerman > . > . > . > > ? ?private void addSpecifiedPorts(String names, int PortType) > ? ?{ > ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); > ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); > > ? ? ? ?if (debug) > ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); > ? ? ? ?while (tok.hasMoreElements()) > ? ? ? ?{ > ? ? ? ? ? ?String PortName = tok.nextToken(); > > // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, > PortType)) > ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, > ? ? ? ? ? ? ? ? ? ?PortType, this); > ? ? ? ?} > ? ?} > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Not that I would use this code, but I don't like a few things about it. First; I don't like the use of StringTokenizer, you should use String.split() method instead. It states in the StringTokenizer class javadoc "StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead. " Second; I don't like that there is 2 "if (!registryError)" blocks. You can easily have 1 block and the second one can be embedded in the first one inside the " if (tm.size() < 1)" condition. Thirdly; Like Mariusz has already stated, using hard coded string array of com ports if all else fails is highly undesirable. This might happen rarely but what if someone gets an error on a machine that has only 2 serial com port and code returns a list of COM1 through 9 ? Also your code suggests that everyone must use your method. In fact you should have taken a more considerate approach. Add a function or param that lets the user choose to favor windows registry detection of the ports first, then if that fails it switches to the standard way of detecting ports. --- George H george.dma at gmail.com From HowardZ at howardz.com Wed Sep 15 03:02:55 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 05:02:55 -0400 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <4C908BBF.7040409@howardz.com> M.Dec-GM, You are looking at what is done if there are some unexplained error. I get no errors, but just case I added COM1 through COM9 as better than nothing. But, this should never occur. I bet you never read the code - the part that looks into the Windows registry to get the full list of all COM ports, both real COM ports, USB/Adapter COM ports, and virtual COM ports. All three types of COM ports are listed together in the windows registry. Gezus, you complain about the one line of error processing and condemn the entire modification! Go back to sleep. Go use the regular RXTX, every time you run any program using RXTX - every one of your COM ports starts going crazy. You may not notice because you don't have any real equipment connected to them. The regular RXTX causes my radio to start transmitting. Also my antenna tuner go start resetting - which can damage it. Howard On 9/15/2010 01:48, M.Dec-GM wrote: > Hi all, > ----- Original Message ----- > From: > To: > Sent: Tuesday, September 14, 2010 10:10 PM > Subject: [Rxtx] JNA > > >> Hi everyone, >> >> I have been playing with jna. > At first most important thing: > Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. > This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... > And, sorry, this looks strictly as a play only... > We are talking: "Art for the Art:. > > Facts: > I don't understand what for doing Java application platform dependend in this part of RXTX??? > Obtaining port list in RXTX works good, and is very easy to change... > > Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. > > So - this:part looks crazy: > // In case of errors, list COM1 through COM9 - it is better than nothing. > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... > Please try to connect to the port from this list.... > "Better than nothing" is to write - No ports, List Error or something like that... > > No comments more... > Mariusz > > > } From mariusz.dec at gmail.com Wed Sep 15 03:23:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 11:23:29 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <4C908BBF.7040409@howardz.com> Message-ID: <88BB6C07D32E45A6B4790486CF6A8A71@mdam2> Hi, I said no comments, but... Level of your asnwer is on the same low level as presented piece of code is. Instead of writing here, it will be better to listen your radio switched from PC.... (if you can transmit, probably you know how to switch it on receiving...). This is clear now that my notices and notices from George H aren't interesting for you - you are the best programmer in the world "who_only_knows_how_to_switch_radio_from_PC". Congratulations... So no comments more..., really. Regards Mariusz ----- Original Message ----- From: To: "M.Dec-GM" Cc: Sent: Wednesday, September 15, 2010 11:02 AM Subject: Re: [Rxtx] JNA > M.Dec-GM, > > You are looking at what is done if there are some unexplained error. > > I get no errors, but just case I added COM1 through COM9 as better than > nothing. > > But, this should never occur. > > I bet you never read the code - the part that looks into the Windows > registry > to get the full list of all COM ports, both real COM ports, USB/Adapter > COM ports, and virtual COM ports. > All three types of COM ports are listed together in the windows registry. > > Gezus, you complain about the one line of error processing and condemn > the entire modification! > Go back to sleep. > Go use the regular RXTX, every time you run any program using RXTX - > every one of your COM ports > starts going crazy. You may not notice because you don't have any real > equipment connected to them. > > The regular RXTX causes my radio to start transmitting. > Also my antenna tuner go start resetting - which can damage it. > > Howard > > On 9/15/2010 01:48, M.Dec-GM wrote: >> Hi all, >> ----- Original Message ----- >> From: >> To: >> Sent: Tuesday, September 14, 2010 10:10 PM >> Subject: [Rxtx] JNA >> >> >>> Hi everyone, >>> >>> I have been playing with jna. >> At first most important thing: >> Ok - everybody has freedom in programming works, but in case that here we are meeting beginners as well, job presented here looks not good, because shows how to complicate simple things. >> This is the fastest way to decrease software quality and to do smog in the heads of the beginners.... >> And, sorry, this looks strictly as a play only... >> We are talking: "Art for the Art:. >> >> Facts: >> I don't understand what for doing Java application platform dependend in this part of RXTX??? >> Obtaining port list in RXTX works good, and is very easy to change... >> >> Another thing - this registry entry (I am using it very often in Windows native applications) may have up to 256 COM ports, each one with complete string (i.e. COM237) and this Register list has ONLY CURRENTLY available ports. >> >> So - this:part looks crazy: >> // In case of errors, list COM1 through COM9 - it is better than nothing. >> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for STUPID list with propaganda: "it is better than nothing", if such list gives no useful information... >> Please try to connect to the port from this list.... >> "Better than nothing" is to write - No ports, List Error or something like that... >> >> No comments more... >> Mariusz >> >> >> } From george.dma at gmail.com Wed Sep 15 03:29:32 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 12:29:32 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C908E72.6020701@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 12:14 PM, HowardZ at howardz.com wrote: > ?George, > > I did not add the tokenizer to that function. > It was already there - look in the CVS - it is in the current RXTX code. > All I did was comment out one line in that function! > > You can preach how terrible the java tokenizer is. > But I don't care. > > Sorry, but you will need to stop using RXTX altogether now. > Because the tokenizer is used by the current RXTX code - I did not add it > nor did I change it. > I merely commented out one line in that function. > > Don't worry, you can stop using Java when you need to do serial I/O. > RXTX has a dreaded tokenizer in it! > You need to stop being emotional and start being logical and use some common sense. I did not know the StringTokenizer code alredy existing in the RXTX source code, so a simple reminder would do and not to be outright defensive as if I am attacking your honor. In fact it could be that the StringTokenizer was used before the the split() method was even created and then it got long lost. Which this is actually a good notice for the current devs. It's not your fault so don't act as if it was. And if it was, I wouldn't want to read your responses based on what you have said today. > Geez!!! ?People criticize the code that I did not modify at all. > You people must never look at the RXTX code in the CVS. > > Second, the first call to read the registry gets the list of all registry > keys in that registry folder. > The second call is in a loop. ?It is reading each one of those registry keys > to get the COM port names. > > Third - you are an idiot. ?It will never fail. ?But, just in case somehow it > does - you are right? > Never say never, defensive programming is always used in practice. ... oh yeah, before I forget. Let me drop down to your level for a few seconds. [Dropping down] Sticks and stones will break my bones but names will never hurt me [Going back up] > We should provide ZERO com ports in the list. > What a great thing to do in the event of a registry read error? > I never thought about it. > Users of your software will love this? > > In my mind have many bad words I'd like to call you, > but I will not type them. > Ah and "idiot" was not a bad word that your typed, it was definitely an insult and you proved yourself to be a hypocrite in this regard. > > Note to myself: Never try to help the RXTX.org people again. > > Howard > You are not helping anyone by name calling, insults and the lack of intellectual curiosity to receive criticism and rebut them at the same level or higher. I regret that you took to my suggestions with such angst. I shall note down not to converse with you unless you show some respect to others. > On 9/15/2010 03:28, George H wrote: >> >> On Tue, Sep 14, 2010 at 11:10 PM, HowardZ at howardz.com >> ?wrote: >>> >>> ?Hi everyone, >>> >>> I have been playing with jna. ?The only downside I can see from using jna >>> is >>> that it makes RXTX dependent on the jna package. ?So, if someday jna is >>> no >>> longer supported, we need to support it - assuming it is open source. >>> >>> Yesterday I downloaded jna.jar and platform.jar from >>> >>> https://jna.dev.java.net/servlets/ProjectDocumentList?folderID=12329&expandFolder=12329&folderID=7408 >>> >>> jna.jar does the work and has built into it libraries for all the >>> operating >>> systems. >>> >>> platform.jar has (I think) all the win32 api calls defined for easy >>> access >>> from java. >>> >>> I modified all my code to use the jna/platform method to access the MS >>> Windows registry (instead of Winregistry). ?None of my programs write to >>> the >>> registry, as I try to keep things platform independent. ?But I sometimes >>> need to read the registry to interface to some software which only runs >>> on >>> MS Windows and uses the registry. ?It seems to work well. >>> >>> BTW, pretty much the only think I have changed in RXTX is to eliminate >>> the >>> checking for valid COM ports every time a program that uses RXTX is >>> started. >>> ?I hate how it raises RTS on all my com ports, as this causes my Amateur >>> Radio to start transmitting. ?So, only for MS Windows, I modified RXTX to >>> read the registry to get a list of all the valid COM ports. >>> >>> Here are some code snipets from my modified RXTXComDriver.java >>> >>> // Begin of added by Howard Zuckerman >>> import com.sun.jna.*; ? ? ? // JNA to call native operating system >>> libraries >>> import com.sun.jna.win32.*; >>> import com.sun.jna.platform.win32.*; >>> import com.sun.jna.platform.win32.WinReg; >>> import com.sun.jna.platform.win32.Advapi32Util; >>> import java.util.Comparator; >>> // End of added by Howard Zuckerman >>> . >>> . >>> . >>> //Begin Added/Modified by Howard Zuckerman >>> ? ? ? ? ? ?String[] h = null; >>> ? ? ? ? ? ?if (osName.toLowerCase().indexOf("windows")!= -1) { // Win7, >>> Vista, XP, etc.. >>> ? ? ? ? ? ? ? ?// For MS Windows, all valid COM ports are determined at >>> boot >>> time >>> ? ? ? ? ? ? ? ?// and all the valid COM ports are listed in the registry. >>> ? ? ? ? ? ? ? ?Boolean registryError = false; >>> ? ? ? ? ? ? ? ?TreeMap tm = new TreeMap(); >>> ? ? ? ? ? ? ? ?try { >>> ? ? ? ? ? ? ? ? ? ?tm = >>> Advapi32Util.registryGetValues(WinReg.HKEY_LOCAL_MACHINE, >>> ? ? ? ? ? ? ? ? ? ? ? ?"HARDWARE\\DEVICEMAP\\SERIALCOMM"); >>> ? ? ? ? ? ? ? ?} catch(Exception e) { >>> ? ? ? ? ? ? ? ? ? ?registryError = true; >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Error reading JNA >>> registry COM port values"); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?System.out.println("RXTXCommDriver: Number of COM >>> Ports = >>> " + tm.size()); >>> ? ? ? ? ? ? ? ? ? ?if (tm.size()< ?1) registryError = true; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?if (!registryError) { >>> ? ? ? ? ? ? ? ? ? ?int len = tm.size(); >>> ? ? ? ? ? ? ? ? ? ?h = new String[len]; >>> ? ? ? ? ? ? ? ? ? ?for (int i=0; i< ?len; i++) { >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = (String) tm.firstEntry().getValue(); >>> ? ? ? ? ? ? ? ? ? ? ? ?h[i] = h[i].trim(); >>> ? ? ? ? ? ? ? ? ? ? ? ?System.out.println("COM port #"+i+"='"+h[i]+"'"); >>> ? ? ? ? ? ? ? ? ? ? ? ?tm.remove(tm.firstEntry().getKey()); >>> ? ? ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?} else { ?// In case of errors, list COM1 through COM9 - >>> it >>> is better than nothing. >>> ? ? ? ? ? ? ? ? ? ?h = new String[] >>> {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?// Sort the COM port names first by length and >>> ? ? ? ? ? ? ? ?// then alphabetically without regards to upper/lower case >>> ? ? ? ? ? ? ? ?StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ? ? ? ? ?Arrays.sort(h, byStringLength ); >>> ? ? ? ? ? ? ? ?//System.out.print("TwoWaySerialComm - com list = "); >>> ? ? ? ? ? ? ? ?for(int i=0; i>> ? ? ? ? ? ? ? ? ? ?//System.out.print(h[i]+" "); >>> ? ? ? ? ? ? ? ? ? ?addSpecifiedPorts(h[i], >>> CommPortIdentifier.PORT_SERIAL); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ? ? ?//System.out.println(""); >>> >>> >>> ? ? ? ? ? ?} else { // This is not a Microsoft Windows Vista/XP/etc. >>> computer >>> >>> ? ? ? ? ? ? ? ?/* >>> ? ? ? ? ? ? ? ?First try to register ports specified in the properties >>> ? ? ? ? ? ? ? ?file. ?If that doesn't exist, then scan for ports. >>> ? ? ? ? ? ? ? ?*/ >>> ? ? ? ?for (int >>> >>> PortType=CommPortIdentifier.PORT_SERIAL;PortType<=CommPortIdentifier.PORT_PARALLEL;PortType++) >>> { >>> ? ? ? ? ? ?if (!registerSpecifiedPorts(PortType)) { >>> ? ? ? ? ? ? ? ?if (!registerKnownPorts(PortType)) { >>> ? ? ? ? ? ? ? ? ? ?registerScannedPorts(PortType); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ?} >>> >>> ? ? ? ?// The following class is for use for sorting Strings where >>> ? ? ? ?// we want shorter Strings first before longer Strings. >>> ? ? ? ?// Strings of the same length are sorted alphabetically >>> ? ? ? ?// without regard to upper or lower case. >>> ? ? ? ?// Example use: >>> ? ? ? ?// h = new String[] >>> {"COM10","COM2","COM30","COM4","COM35","COM6","COM7","COM8","COM32"}; >>> ? ? ? ?// StringLengthComparator byStringLength = new >>> StringLengthComparator(); >>> ? ? ? ?// Arrays.sort(h, byStringLength ); >>> ? ? ? ?class StringLengthComparator implements Comparator ?{ >>> ? ? ? ? ? ?// Comparator interface requires defining compare method. >>> ? ? ? ? ? ?public int compare(String a, String b) { >>> ? ? ? ? ? ? ? ?int comp = a.length() - b.length(); >>> ? ? ? ? ? ? ? ?if (comp != 0) { >>> ? ? ? ? ? ? ? ? ? ?//... If different lengths, we're done. >>> ? ? ? ? ? ? ? ? ? ?return comp; >>> ? ? ? ? ? ? ? ?} else { >>> ? ? ? ? ? ? ? ? ? ?//... If equal lengths, sort alphabetically. >>> ? ? ? ? ? ? ? ? ? ?return a.toLowerCase().compareTo( b.toLowerCase() ); >>> ? ? ? ? ? ? ? ?} >>> ? ? ? ? ? ?} >>> ? ? ? ?} >>> // End added/modified by Howard Zuckerman >>> . >>> . >>> . >>> >>> ? ?private void addSpecifiedPorts(String names, int PortType) >>> ? ?{ >>> ? ? ? ?final String pathSep = System.getProperty("path.separator", ":"); >>> ? ? ? ?final StringTokenizer tok = new StringTokenizer(names, pathSep); >>> >>> ? ? ? ?if (debug) >>> ? ? ? ? ? ?System.out.println("\nRXTXCommDriver:addSpecifiedPorts()"); >>> ? ? ? ?while (tok.hasMoreElements()) >>> ? ? ? ?{ >>> ? ? ? ? ? ?String PortName = tok.nextToken(); >>> >>> // Commented out by Howard Zuckerman ? ? ? ? ? ?if (testRead(PortName, >>> PortType)) >>> ? ? ? ? ? ? ? ?CommPortIdentifier.addPortName(PortName, >>> ? ? ? ? ? ? ? ? ? ?PortType, this); >>> ? ? ? ?} >>> ? ?} >>> >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> Not that I would use this code, but I don't like a few things about it. >> First; I don't like the use of StringTokenizer, you should use >> String.split() method instead. >> >> It states in the StringTokenizer class javadoc >> >> "StringTokenizer is a legacy class that is retained for compatibility >> reasons although its use is discouraged in new code. It is recommended >> that anyone seeking this functionality use the split ?method of String >> or the java.util.regex package instead. " >> >> Second; I don't like that there is 2 "if (!registryError)" blocks. You >> can easily have 1 block and the second one can be embedded in the >> first one inside the " if (tm.size()< ?1)" condition. >> >> Thirdly; Like Mariusz has already stated, using hard coded string >> array of com ports if all else fails is highly undesirable. This might >> happen rarely but what if someone gets an error on a machine that has >> only 2 serial com port and code returns a list of COM1 through 9 ? >> >> Also your code suggests that everyone must use your method. In fact >> you should have taken a more considerate approach. Add a function or >> param that lets the user choose to favor windows registry detection of >> the ports first, then if that fails it switches to the standard way of >> detecting ports. >> >> --- >> George H >> george.dma at gmail.com >> > From HowardZ at howardz.com Wed Sep 15 04:33:54 2010 From: HowardZ at howardz.com (HowardZ at howardz.com) Date: Wed, 15 Sep 2010 06:33:54 -0400 Subject: [Rxtx] JNA In-Reply-To: References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> Message-ID: <4C90A112.3090205@howardz.com> Well George, I woke up at 3:30 this morning, couldn't get back to sleep, and read my email. I get loads of criticism that I do not deserve. This makes me angry, and thus won't get back to sleep and will work today with only 4 hours of sleep. Yes, it makes me feel like the RXTX email list is full of idiots. Yes, "idiot" is an insult, but I was thinking of far worse words. You qualified, as you criticise a code snipet that I did not change. If it was just you - OK, but it was a few people. Makes me think that very few people actually fetch the RXTX code from the CVS, and build it themselves. Not too surprising, as it was a difficult thing for me to setup, and I can only build it for 32bit and 64 bit Microsoft Windows. The other gentleman complains that in the event of a registry error, I added COM1 to COM9 as something better than nothing. Thus he considers the complete effort terrible, and a complete waste. I suppose it is natural for some people to condemn anything new or different. The registry read should never fail, but I figured just in case it is better to have a few COM ports defined rather than have none. I suppose an alternative error processing can be to do the testing of all possible COM port numbers that was done before. Even if the criticisms were valid, it is not the point. I did not post the code snipets to get a critical code review. I can post every single existing RXTX java file and c code file and get hundreds of complaints about how poorly it is written. When I compile RXTX the compilers issue many warnings about unsafe or improper language usage. This does not matter to me - as RXTX works - and fulfills a major functional need. I posted the code snipet, not for a code review, but to show how easy (and useful) it is to use jna.jar and platform.jar The point is to support the idea others had posted a few weeks ago concerning rewriting RXTX to use jna. BTW, nobody has asked me to email them the single RXTX java file I modified. Probably because nobody notices nor cares that every COM port device gets messed with (RTS raised) every time a program using RXTX is run. Only people like me with thousands of dollars of radio equipment connected to COM ports for computer control. If someone likes the concept of changing this one RXTX java file, they are free to do it their own way. I am not planning to place this into the CVS. Why? Because I do not think everyone will like RXTX being dependent on the jna.jar/platform.jar at this time. A few weeks ago there were discussions of moving RXTX to jna and elminating all the C code and the OS specific libraries from RXTX. I showed a sample of using jna/platform to access the windows registry - something that in the past was difficult to do in java. Converting to jna, if done, will be a large effort and require development/testing on every operating system platform. In the Java code will be tests for which operating system it is running on (as currently is done in some parts of the Java code) with operating specific jna calls (as currently is done in the C code). The nice result will be all java code, with no C code, no operating specific libraries, and no need to have many computers available to rebuild on every supported platform after a software change. I remember some junior programmers I worked with in the 1990s who were maintaining code - being very displeased with how the original programmer wrote it. He had left the company, but he thought in strange ways. He typically wrote six levels of inheritance for a class - and only the last level is ever used. It made modifying any code he wrote very difficult. He was a brilliant man, but made things overly complicated. Sometimes I think he just wanted to try out features he read about, even when there was no need for it. Well this junior programmer changed it, and was surprised that nothing worked and that it took a large amount of time to get everything error free. It was no surprise to me. No matter how messy existing code might be, it is a major effort to rewrite anything because nobody can write one screen worth of code without introducing some kind of error. And it takes time to test and weed out all these errors. This does not mean that one should not try to make changes, just to realize it will be a large amount of work. Howard From hybris0 at gmail.com Wed Sep 15 04:46:55 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 12:46:55 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: Nobody can help on this? 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 05:05:48 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 14:05:48 +0300 Subject: [Rxtx] JNA In-Reply-To: <4C90A112.3090205@howardz.com> References: <4C8FD6B0.9070306@howardz.com> <4C908E72.6020701@howardz.com> <4C90A112.3090205@howardz.com> Message-ID: On Wed, Sep 15, 2010 at 1:33 PM, HowardZ at howardz.com wrote: > ?Well George, > > I woke up at 3:30 this morning, couldn't get back to sleep, and read my > email. > I get loads of criticism that I do not deserve. ?This makes me angry, and > thus > won't get back to sleep and will work today with only 4 hours of sleep. > It is understandable to get angry at criticisms that you feel you may not deserve. Though like I said I did not know which parts of the code was added by you and which were already there. So you gotta suck it in and just explain that the code of the critique in question was not yours, so you're free of responsibility. Hell you might as well add a positive note and mention that yes it would be a good idea to replace it and use .split(), though that's up to you, but it's what I would have done. > Yes, it makes me feel like the RXTX email list is full of idiots. > Yes, "idiot" is an insult, but I was thinking of far worse words. > > You qualified, as you criticise a code snipet that I did not change. ?If it > was > just you - OK, but it was a few people. > So I qualified as an idiot because there was more than 1 person criticizing your code snippet. Sorry but I feel that kind of reasoning is unjustified to be used. FYI I do have the source code of rxtx, I have not scanned through the java code but I have gone through the C code. Plus I don't have to re-scan everything every time someone posts some code online. That would just take too much of my time, on the other hand if it was committed to the CVS then I would just do an update and view the annotations of what changed. > Makes me think that very few people actually fetch the RXTX code from the > CVS, > and build it themselves. ?Not too surprising, as it was a difficult thing > for me to setup, > and I can only build it for 32bit and 64 bit Microsoft Windows. > > The other gentleman complains that in the event of a registry error, > I added COM1 to COM9 as something better than nothing. ?Thus he considers > the complete effort terrible, and a complete waste. > > I suppose it is natural for some people to condemn anything new or > different. > This is not what is happening, if this was true then Adrian Crum would have been "condemned" for proposing a re-write. He wasn't, in fact a large discussion ensued, code was posted, it gets reviewed no matter what and people offer their opinions and advice. This is what Mariusz and I have done in this instance. It's fairly easy as take it or leave it. The fact that you insulted me based on your emotions made me respond the way I did, aside from that I could not have cared less. > The registry read should never fail, but I figured just in case it is better > to have > ?a few COM ports defined rather than have none. ?I suppose an alternative > error processing > can be to do the testing of all possible COM port numbers that was done > before. > Like I said before, never say never, sometimes things fail for the darnedest reasons and you know this, that's why you added the just in case part. Mariusz had a big problem with it. I offered a more reasonable option, if you read it, I said that you could fall back to the old way of doing things. > Even if the criticisms were valid, it is not the point. ?I did not post the > code > snipets to get a critical code review. > > I can post every single existing RXTX java file and c code file and get > hundreds of complaints about how poorly > it is written. ?When I compile RXTX the compilers issue many warnings about > unsafe or improper > language usage. ?This does not matter to me - as RXTX works - and fulfills a > major functional need. > Sadly you can't get away from this. Any code that is posted online for the whole world to see get reviewed. Even if it is not yours, or partially yours. Likewise I can post code from the linux kernel and someone might criticize it, even though I maybe changed the name of a variable. But like I said before, why get so angry for something you didn't even do anyways. A simple explanation is all it needs. > I posted the code snipet, not for a code review, but to show how easy (and > useful) it is to use jna.jar and platform.jar > The point is to support the idea others had posted a few weeks ago > concerning rewriting RXTX to use jna. > That's good, i'm sure someone found it useful, I even thought it was useful ... well only for people running windows. And at that I believe it should be optional (as I have already stated) maybe someone doesn't want to the ports that way, maybe someone somewhere wants those RTS signals to be raised. Literally what do you know if that's a good thing or a bad thing. You only proved that to your specific application it was undesirable, maybe to someone else it is desired. > BTW, nobody has asked me to email them the single RXTX java file I modified. > Probably because nobody notices nor cares that every COM port device gets > messed with (RTS raised) every time a program using RXTX is run. ?Only > people like me > with thousands of dollars of radio equipment connected to COM ports for > computer control. > Lots of people post code and patches online. Not many will just blindly copy/paste it and start using it. Maybe they don't care, either way at this point I couldn't care less. Being committed to the CVS is the only time I would even remotely precipitate and iota of care, but that's just me, I can't speak for anyone else. > If someone likes the concept of changing this one RXTX java file, they are > free to do it their own way. ?I am not planning to place this into the CVS. > Why? Because I do not think everyone will like RXTX being dependent > on the jna.jar/platform.jar at this time. > Actually the devs agreed to have a JNA directory where people can test things out. I think the people who want to see JNA succeed would be interested. > A few weeks ago there were discussions of moving RXTX to jna and elminating > all the C code > and the OS specific libraries from RXTX. > > I showed a sample of using jna/platform to access the windows registry - > something that > in the past was difficult to do in java. > > Converting to jna, if done, will be a large effort and require > development/testing on every > operating system platform. ?In the Java code will be tests for which > operating system > it is running on (as currently is done in some parts of the Java code) with > operating specific > ?jna calls (as currently is done in the C code). ?The nice result will be > all java code, with > no C code, no operating specific libraries, and no need to have many > computers available > to rebuild on every supported platform after a software change. > > I remember some junior programmers I worked with in the 1990s who were > maintaining code - being very displeased with > how the original programmer wrote it. ?He had left the company, but he > thought in strange ways. > He typically wrote six levels of inheritance for a class - and only the last > level is ever used. ?It > made modifying any code he wrote very difficult. ?He was a brilliant man, > but made things > overly complicated. ?Sometimes I think he just wanted to try out features he > read about, > even when there was no need for it. ?Well this junior programmer changed it, > and > was surprised that nothing worked and that it took a large amount of time to > get everything > error free. > This part got out of topic but I wouldn't call someone brilliant if they made things overly complicated. Just like Occam's razor would state that the simplest solution is usually the best. > It was no surprise to me. ?No matter how messy existing code might be, it is > a major effort > to rewrite anything because nobody can write one screen worth of code > without introducing > some kind of error. ?And it takes time to test and weed out all these > errors. > Agree > This does not mean that one should not try to make changes, just to realize > it will be a > large amount of work. > > Howard > I wish Adrian Crum the best of luck in his re-write effort. From mariusz.dec at gmail.com Wed Sep 15 05:35:55 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 13:35:55 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ------------------------------------------------------------------------------ _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 05:56:26 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 13:56:26 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM > Hi, > Using XON-XOFF software handshake protocol has a some limitations - bytes > for XON and for XOFF are not usable, so you shouldn't transfer binary data > through channel. > This is why I am not using this protocol at all. > But it isn't answer yet :) > > Maybe this helps: > 1. Please check if codes for XON/XOFF are identical in host and client. > 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be > defined by user and I did a mistake - I have forgotten to switch automatic > XON/XOFF in tool, but both codes were 0x00 by default... > You know what it means when binary data were transmitted... crazy :). > 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way > only... > 4. Looking on the problem from another side - think if XON/XOFF is > necessary for now, maybe bigger buffer will be enough, or simply write > yourself the > service for XON/XOFF - this very easy, and you may use my examples for this > job. > There is enough to check XOFF in SerialReader and stop writing until XON > will come... > > Good luck :) > Mariusz > > > > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 12:46 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > Nobody can help on this? > > 2010/9/7 Hybris > >> Hi, >> i have a problem under Linux. >> I often used the library (last stable release 2.1) without any problem >> in this environment. >> >> Without any other clues at the moment i am blaming the fact i am >> talking a device that requires XON/XOFF as flow control method. A >> method i never used before. >> >> Under windows i have no problems, under Linux commands are received by >> the device but i do not get replies or i get truncated replies (log >> follows) >> >> I am using the seial port builtin the motherboard, no usb converters. >> >> I initialize the port this way: >> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >> serialPort.setInputBufferSize(256); >> serialPort.setOutputBufferSize(256); >> serialPort.enableReceiveTimeout(1000); >> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >> >> The protocol used is an ascii protocol with CR/LF terminator for messages. >> >> The output i get on windows for a cycle of request/response (one per >> second) is this (>>> from PC to the device, <<< from device to PC): >> >> 2010-09-07 12.18.07: <<< 1TS000033 >> 2010-09-07 12.18.08: >>> 1TS >> 2010-09-07 12.18.08: <<< 1TS000033 >> 2010-09-07 12.18.09: >>> 1TS >> 2010-09-07 12.18.09: <<< 1TS000033 >> 2010-09-07 12.18.10: >>> 1TS >> 2010-09-07 12.18.10: <<< 1TS000033 >> 2010-09-07 12.18.11: >>> 1TS >> 2010-09-07 12.18.11: <<< 1TS000033 >> >> On linux instead i have this: >> >> 2010-09-07 12.16.40: >>> 1TS >> timeout >> 2010-09-07 12.16.42: >>> 1TS >> 2010-09-07 12.16.42: <<< 3 >> 2010-09-07 12.16.43: >>> 1TS >> timeout >> 2010-09-07 12.16.45: >>> 1TS >> timeout >> 2010-09-07 12.16.47: >>> 1TS >> timeout >> 2010-09-07 12.16.49: >>> 1TS >> timeout >> 2010-09-07 12.16.51: >>> 1TS >> timeout >> 2010-09-07 12.16.53: >>> 1TS >> 2010-09-07 12.16.53: <<< 3 >> 2010-09-07 12.16.54: >>> 1TS >> timeout >> 2010-09-07 12.16.56: >>> 1TS >> 2010-09-07 12.16.56: <<< 1TS000033 >> 2010-09-07 12.16.57: >>> 1TS >> 2010-09-07 12.16.58: <<< 3 >> 2010-09-07 12.16.59: >>> 1TS >> timeout >> 2010-09-07 12.17.01: >>> 1TS >> timeout >> >> Any ideas? >> > > ------------------------------ > > _______________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Sep 15 06:23:33 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 15:23:33 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: >> The protocol used is an ascii protocol with CR/LF terminator for messages. In Windows CR/LF is often used in line termination and this convention is buried in lots of code ... whereas in *nix world LF only is used. So could this be related to your issue? It could be helpful if you described how you grabbed the dump of what is happening, now it is unclear weather you have observed the communication on the PC side, or device side, or on the actual serial communication line. Also it might be useful to show the code that actually read/write the port, not just the port initialization. br Kusti From mariusz.dec at gmail.com Wed Sep 15 06:27:29 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Wed, 15 Sep 2010 14:27:29 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? -------------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 06:42:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:42:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: The output i reported is written by my java application when it sends and when it receive. As i said under linux i do not have a powerful tool like portmon on windows (funny because usually is the other way round) The read and write is pretty simple and is done using the streams coming from the serial ports and yes, after each write i do a flush, even if i do not use buffered streams because i saw it must be done otherwise stuff remains on the pc side. 2010/9/15 Kustaa Nyholm > > >> The protocol used is an ascii protocol with CR/LF terminator for > messages. > > In Windows CR/LF is often used in line termination and this convention > is buried in lots of code ... whereas in *nix world LF only is used. > > So could this be related to your issue? > > It could be helpful if you described how you grabbed the dump > of what is happening, now it is unclear weather you have > observed the communication on the PC side, or device side, or > on the actual serial communication line. > > Also it might be useful to show the code that actually read/write > the port, not just the port initialization. > > 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 hybris0 at gmail.com Wed Sep 15 06:48:32 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 14:48:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail > Ok, > Have you a Java source of the application? > > If yes, you may do a trick, which I did when I was fighting with close() in > Linux :) > I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to > the application folder. > > !!! > You have to remove EACH copy of the RXTX.jar from the system, and stay with > application sources with RXTX inside. > !!! > > In this case you will have very deep access to RXTX sources > Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF > codes. > > As a final/least solution is own XON/XOFF protocoll - very simple - believe > me :) > I think that it will be faster to write than looking for Linux > codes/problems. > > OR > > maybe there is a Java software mistake in Serial service which is better > visible/more critical in Linux? > > Switch XON/XOFF at all and try how it works. > You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, > assumming 10 bytes of data + CRLF. > > OR > Another idea - try to send device's XON after first query... > > 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - > what the computer is this - PC or small PDA, ARM? > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 1:56 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > The protocol is not binary and the device works only that way. > > I'll do some of the checks you mentioned but it seems fair to me expecting > rxtx to behave the same way on windows and linux. > > I recognize that it can also be a buffer problem, or a XON/XOFF value > problem....unfortunately linux does not offer any decent tool for sniffing > the serial at OS level as far as i know. > > 2010/9/15 M.Dec-GM > >> Hi, >> Using XON-XOFF software handshake protocol has a some limitations - bytes >> for XON and for XOFF are not usable, so you shouldn't transfer binary data >> through channel. >> This is why I am not using this protocol at all. >> But it isn't answer yet :) >> >> Maybe this helps: >> 1. Please check if codes for XON/XOFF are identical in host and client. >> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >> be defined by user and I did a mistake - I have forgotten to switch >> automatic XON/XOFF in tool, but both codes were 0x00 by default... >> You know what it means when binary data were transmitted... crazy :). >> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >> only... >> 4. Looking on the problem from another side - think if XON/XOFF is >> necessary for now, maybe bigger buffer will be enough, or simply write >> yourself the >> service for XON/XOFF - this very easy, and you may use my examples for >> this job. >> There is enough to check XOFF in SerialReader and stop writing until XON >> will come... >> >> Good luck :) >> Mariusz >> >> >> >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 12:46 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> Nobody can help on this? >> >> 2010/9/7 Hybris >> >>> Hi, >>> i have a problem under Linux. >>> I often used the library (last stable release 2.1) without any problem >>> in this environment. >>> >>> Without any other clues at the moment i am blaming the fact i am >>> talking a device that requires XON/XOFF as flow control method. A >>> method i never used before. >>> >>> Under windows i have no problems, under Linux commands are received by >>> the device but i do not get replies or i get truncated replies (log >>> follows) >>> >>> I am using the seial port builtin the motherboard, no usb converters. >>> >>> I initialize the port this way: >>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>> serialPort.setInputBufferSize(256); >>> serialPort.setOutputBufferSize(256); >>> serialPort.enableReceiveTimeout(1000); >>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>> >>> The protocol used is an ascii protocol with CR/LF terminator for >>> messages. >>> >>> The output i get on windows for a cycle of request/response (one per >>> second) is this (>>> from PC to the device, <<< from device to PC): >>> >>> 2010-09-07 12.18.07: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 >>> 2010-09-07 12.18.11: >>> 1TS >>> 2010-09-07 12.18.11: <<< 1TS000033 >>> >>> On linux instead i have this: >>> >>> 2010-09-07 12.16.40: >>> 1TS >>> timeout >>> 2010-09-07 12.16.42: >>> 1TS >>> 2010-09-07 12.16.42: <<< 3 >>> 2010-09-07 12.16.43: >>> 1TS >>> timeout >>> 2010-09-07 12.16.45: >>> 1TS >>> timeout >>> 2010-09-07 12.16.47: >>> 1TS >>> timeout >>> 2010-09-07 12.16.49: >>> 1TS >>> timeout >>> 2010-09-07 12.16.51: >>> 1TS >>> timeout >>> 2010-09-07 12.16.53: >>> 1TS >>> 2010-09-07 12.16.53: <<< 3 >>> 2010-09-07 12.16.54: >>> 1TS >>> timeout >>> 2010-09-07 12.16.56: >>> 1TS >>> 2010-09-07 12.16.56: <<< 1TS000033 >>> 2010-09-07 12.16.57: >>> 1TS >>> 2010-09-07 12.16.58: <<< 3 >>> 2010-09-07 12.16.59: >>> 1TS >>> timeout >>> 2010-09-07 12.17.01: >>> 1TS >>> timeout >>> >>> Any ideas? >>> >> >> ------------------------------ >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.dma at gmail.com Wed Sep 15 06:56:37 2010 From: george.dma at gmail.com (George H) Date: Wed, 15 Sep 2010 15:56:37 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > Will this work ? http://www.rolf-schroedter.de/moni/ -- George H george.dma at gmail.com > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm >> >> >> The protocol used is an ascii protocol with CR/LF terminator for >> >> messages. >> >> In Windows CR/LF is often used in line termination and this convention >> is buried in lots of code ... whereas in *nix world LF only is used. >> >> So could this be related to your issue? >> >> It could be helpful if you described how you grabbed the dump >> of what is happening, now it is unclear weather you have >> observed the communication on the PC side, or device side, or >> on the actual serial communication line. >> >> Also it might be useful to show the code that actually read/write >> the port, not just the port initialization. >> >> br Kusti >> >> >> >> _______________________________________________ >> 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 Kustaa.Nyholm at planmeca.com Wed Sep 15 07:21:42 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 16:21:42 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > The output i reported is written by my java application when it sends and when > it receive. I still do not quite understand what happens at the code level. Your program outputs: > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout So your code sends '1TS' and then get timeout? On write? Why it only send three bytes, or how do you know it only sends three bytes, what I'm trying to say is that if I had programmed this the code would look something like: outstream.write(bytestosend,0,bytestosend.length); and thus I would not know that I've only sent three bytes. So evidently your code is different and that's why I suggested that it might be helpful to actually see the code. Or am I missing something here? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 07:26:11 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 15:26:11 +0200 Subject: [Rxtx] JNA In-Reply-To: <95E46F3E54BF4D77935D0B034703389C@mdam2> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> Message-ID: <20100915132611.GE7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: > Hi all, > So - this:part looks crazy: > > // In case of errors, list COM1 through COM9 - it is better than nothing. > > h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; > > What for maybe better: `a doubtful'? > list [...]: "it is better than nothing", > if such list gives no useful information... > > Please try to connect to the port from this list.... "Better > than nothing" is to write - No ports, List Error or something > like that... Indeed the application shall have a way to notice the problem that should never occure. Also, a better fallback probably would be the classic port enumeration code (althrough I also dislike if this `probing' modifies control lines of those ports; but I'm not neutral here anyway, because I dislike such `browsing' stuff and would prefere to be able to enter the port name to use, as used to be on classic unices and even if the serial port happens to be a terminal or even a FIFO, almost everything works). Also, it might be insufficient to present the list of currently available serial ports, for example in a configuration dialog I may wish to configure ports which currently are not connected. AFAIK, this for example is simply not possible with windows hardware device manager, because in case the USB device is not plugged you have it in no list where you could click it; bad... So I think a good application should allow users to specify ports directly anyway and no such fallback would be required. But back to topic, in case /everything/ fails, having a default list of `usual' port name IMHO does not seem too bad. Me, for examples, knows many workstation installations with COM ports usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, so such a fallback could help the majority of users where both registry lookup and `port probing' fail. Of course it is hard to tell what will happen on systems of the windows users where registry lookups fail, probably nothing will work anyway, but who knows :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 07:31:22 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:31:22 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> Message-ID: <1CD57CB0C6974785BFAB43E383D60295@mdam2> And what about this problem - how it works WITHOUT XON/XOFF? Assuming (with overhead) 12 bits per byte and 12 bytes, your transmission duration is 2.5 ms. If you said that system is enough fast, should find 2,5 ms in each second to serve this packet :) BTW: Netbeans for Linux is very easy to install and use.... no differences :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 2:48 PM Subject: Re: [Rxtx] XON XOFF under linux I am working on a PC, no PDAs....i exclude the fact that linux is too slow. I already used RXTX under linux with no problem at all. Also, since i was not unable to debug the application in Linux i debugged it in Windows running in a virtual machine under the same Linux. Even if XON/XOFF is so simple i keep its implementations as a last resort. Fortunately i develop on Linux but, in this case, deploy on windows so i can workaround it this way.... debugging is a bit tedious done this way but the protocol is sufficiently simple to not require too much debugging. In fact i am done with it. I already tried to link to the RXTX sources but it seems that the flow control stuff is done in the C part. 2010/9/15 M.Dec-GMail Ok, Have you a Java source of the application? If yes, you may do a trick, which I did when I was fighting with close() in Linux :) I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to the application folder. !!! You have to remove EACH copy of the RXTX.jar from the system, and stay with application sources with RXTX inside. !!! In this case you will have very deep access to RXTX sources Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF codes. As a final/least solution is own XON/XOFF protocoll - very simple - believe me :) I think that it will be faster to write than looking for Linux codes/problems. OR maybe there is a Java software mistake in Serial service which is better visible/more critical in Linux? Switch XON/XOFF at all and try how it works. You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, assumming 10 bytes of data + CRLF. OR Another idea - try to send device's XON after first query... 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - what the computer is this - PC or small PDA, ARM? Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 1:56 PM Subject: Re: [Rxtx] XON XOFF under linux The protocol is not binary and the device works only that way. I'll do some of the checks you mentioned but it seems fair to me expecting rxtx to behave the same way on windows and linux. I recognize that it can also be a buffer problem, or a XON/XOFF value problem....unfortunately linux does not offer any decent tool for sniffing the serial at OS level as far as i know. 2010/9/15 M.Dec-GM Hi, Using XON-XOFF software handshake protocol has a some limitations - bytes for XON and for XOFF are not usable, so you shouldn't transfer binary data through channel. This is why I am not using this protocol at all. But it isn't answer yet :) Maybe this helps: 1. Please check if codes for XON/XOFF are identical in host and client. 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should be defined by user and I did a mistake - I have forgotten to switch automatic XON/XOFF in tool, but both codes were 0x00 by default... You know what it means when binary data were transmitted... crazy :). 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way only... 4. Looking on the problem from another side - think if XON/XOFF is necessary for now, maybe bigger buffer will be enough, or simply write yourself the service for XON/XOFF - this very easy, and you may use my examples for this job. There is enough to check XOFF in SerialReader and stop writing until XON will come... Good luck :) Mariusz ----- Original Message ----- From: Hybris To: rxtx at qbang.org Sent: Wednesday, September 15, 2010 12:46 PM Subject: Re: [Rxtx] XON XOFF under linux Nobody can help on this? 2010/9/7 Hybris Hi, i have a problem under Linux. I often used the library (last stable release 2.1) without any problem in this environment. Without any other clues at the moment i am blaming the fact i am talking a device that requires XON/XOFF as flow control method. A method i never used before. Under windows i have no problems, under Linux commands are received by the device but i do not get replies or i get truncated replies (log follows) I am using the seial port builtin the motherboard, no usb converters. I initialize the port this way: CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); serialPort.setInputBufferSize(256); serialPort.setOutputBufferSize(256); serialPort.enableReceiveTimeout(1000); serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | RXTXPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); The protocol used is an ascii protocol with CR/LF terminator for messages. The output i get on windows for a cycle of request/response (one per second) is this (>>> from PC to the device, <<< from device to PC): 2010-09-07 12.18.07: <<< 1TS000033 2010-09-07 12.18.08: >>> 1TS 2010-09-07 12.18.08: <<< 1TS000033 2010-09-07 12.18.09: >>> 1TS 2010-09-07 12.18.09: <<< 1TS000033 2010-09-07 12.18.10: >>> 1TS 2010-09-07 12.18.10: <<< 1TS000033 2010-09-07 12.18.11: >>> 1TS 2010-09-07 12.18.11: <<< 1TS000033 On linux instead i have this: 2010-09-07 12.16.40: >>> 1TS timeout 2010-09-07 12.16.42: >>> 1TS 2010-09-07 12.16.42: <<< 3 2010-09-07 12.16.43: >>> 1TS timeout 2010-09-07 12.16.45: >>> 1TS timeout 2010-09-07 12.16.47: >>> 1TS timeout 2010-09-07 12.16.49: >>> 1TS timeout 2010-09-07 12.16.51: >>> 1TS timeout 2010-09-07 12.16.53: >>> 1TS 2010-09-07 12.16.53: <<< 3 2010-09-07 12.16.54: >>> 1TS timeout 2010-09-07 12.16.56: >>> 1TS 2010-09-07 12.16.56: <<< 1TS000033 2010-09-07 12.16.57: >>> 1TS 2010-09-07 12.16.58: <<< 3 2010-09-07 12.16.59: >>> 1TS timeout 2010-09-07 12.17.01: >>> 1TS timeout Any ideas? ---------------------------------------------------------------------- _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:38:31 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:38:31 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: it sends 5 bytes, \r\n are printed and the output goes on the next line as a side effect (sorry if i did not point it out). anyway the code: sh.write("1TS\r\n"); where sh.write does this: public void write(String s) throws IOException { debug(String.format(">>> %s", s)); outputStream.write(s.getBytes()); } outputStream is a bare OutputStream obtained from the serial port on the reading side i use a buffered reader to read lines, the doc states that a line is ended by \n or \r\n so it should be platform indepentent public String readLine() throws IOException { String s = reader.readLine(); debug(String.format("<<< %s", s)); return s; } reader is a BufferedReader built around the serialport input stream reader = new BufferedReader(new InputStreamReader(is)); 2010/9/15 Kustaa Nyholm > > > > > The output i reported is written by my java application when it sends and > when > > it receive. > > I still do not quite understand what happens at the code level. > > Your program outputs: > > > On linux instead i have this: > > > > 2010-09-07 12.16.40: >>> 1TS > > timeout > > 2010-09-07 12.16.42: >>> 1TS > > 2010-09-07 12.16.42: <<< 3 > > 2010-09-07 12.16.43: >>> 1TS > > timeout > > So your code sends '1TS' and then get timeout? On write? > > Why it only send three bytes, or how do you know it only sends three bytes, > what I'm trying to say is that if I had programmed this the code would look > something like: > > outstream.write(bytestosend,0,bytestosend.length); > > and thus I would not know that I've only sent three bytes. So evidently > your code is different and that's why I suggested that it might be > helpful to actually see the code. > > Or am I missing something here? > > 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 andy at g0poy.com Wed Sep 15 07:40:16 2010 From: andy at g0poy.com (Andy Eskelson) Date: Wed, 15 Sep 2010 14:40:16 +0100 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915144016.2630de90@g0poy-server.site> Would strace help you? I've seen some references to this particularly with the -e read=set and -e write=set options. Trouble is, that I don't fully understand strace :-( Andy On Wed, 15 Sep 2010 14:42:23 +0200 Hybris wrote: > The output i reported is written by my java application when it sends and > when it receive. > As i said under linux i do not have a powerful tool like portmon on windows > (funny because usually is the other way round) > > The read and write is pretty simple and is done using the streams coming > from the serial ports and yes, after each write i do a flush, even if i do > not use buffered streams because i saw it must be done otherwise stuff > remains on the pc side. > > > 2010/9/15 Kustaa Nyholm > > > > > >> The protocol used is an ascii protocol with CR/LF terminator for > > messages. > > > > In Windows CR/LF is often used in line termination and this convention > > is buried in lots of code ... whereas in *nix world LF only is used. > > > > So could this be related to your issue? > > > > It could be helpful if you described how you grabbed the dump > > of what is happening, now it is unclear weather you have > > observed the communication on the PC side, or device side, or > > on the actual serial communication line. > > > > Also it might be useful to show the code that actually read/write > > the port, not just the port initialization. > > > > br Kusti > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > From hybris0 at gmail.com Wed Sep 15 07:40:04 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:04 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: i was not able to get it work....it does not capture anything.... 2010/9/15 George H > On Wed, Sep 15, 2010 at 3:42 PM, Hybris wrote: > > The output i reported is written by my java application when it sends and > > when it receive. > > As i said under linux i do not have a powerful tool like portmon on > windows > > (funny because usually is the other way round) > > > > Will this work ? http://www.rolf-schroedter.de/moni/ > > -- > George H > george.dma at gmail.com > > > The read and write is pretty simple and is done using the streams coming > > from the serial ports and yes, after each write i do a flush, even if i > do > > not use buffered streams because i saw it must be done otherwise stuff > > remains on the pc side. > > > > > > 2010/9/15 Kustaa Nyholm > >> > >> >> The protocol used is an ascii protocol with CR/LF terminator for > >> >> messages. > >> > >> In Windows CR/LF is often used in line termination and this convention > >> is buried in lots of code ... whereas in *nix world LF only is used. > >> > >> So could this be related to your issue? > >> > >> It could be helpful if you described how you grabbed the dump > >> of what is happening, now it is unclear weather you have > >> observed the communication on the PC side, or device side, or > >> on the actual serial communication line. > >> > >> Also it might be useful to show the code that actually read/write > >> the port, not just the port initialization. > >> > >> br Kusti > >> > >> > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 07:40:59 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 15:40:59 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <1CD57CB0C6974785BFAB43E383D60295@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: the device requires XON/XOFF i don't get the hint about Netbeans that, btw i am using. 2010/9/15 M.Dec-GM > And what about this problem - how it works WITHOUT XON/XOFF? > Assuming (with overhead) 12 bits per byte and 12 bytes, your > transmission duration is 2.5 ms. > If you said that system is enough fast, should find 2,5 ms in each second > to serve this packet :) > > BTW: Netbeans for Linux is very easy to install and use.... no differences > :) > > Mariusz > > ----- Original Message ----- > *From:* Hybris > *To:* rxtx at qbang.org > *Sent:* Wednesday, September 15, 2010 2:48 PM > *Subject:* Re: [Rxtx] XON XOFF under linux > > I am working on a PC, no PDAs....i exclude the fact that linux is too slow. > I already used RXTX under linux with no problem at all. > Also, since i was not unable to debug the application in Linux i debugged > it in Windows running in a virtual machine under the same Linux. > > Even if XON/XOFF is so simple i keep its implementations as a last resort. > Fortunately i develop on Linux but, in this case, deploy on windows so i > can workaround it this way.... debugging is a bit tedious done this way but > the protocol is sufficiently simple to not require too much debugging. In > fact i am done with it. > > I already tried to link to the RXTX sources but it seems that the flow > control stuff is done in the C part. > > 2010/9/15 M.Dec-GMail > >> Ok, >> Have you a Java source of the application? >> >> If yes, you may do a trick, which I did when I was fighting with close() >> in Linux :) >> I am using Netbeans, and I have copied RXTX sources tree (gno.io....) to >> the application folder. >> >> !!! >> You have to remove EACH copy of the RXTX.jar from the system, and stay >> with application sources with RXTX inside. >> !!! >> >> In this case you will have very deep access to RXTX sources >> Java-JNI interface and I hope it will be enough for debugging Linux XON/XOFF >> codes. >> >> As a final/least solution is own XON/XOFF protocoll - very simple - >> believe me :) >> I think that it will be faster to write than looking for Linux >> codes/problems. >> >> OR >> >> maybe there is a Java software mistake in Serial service which is better >> visible/more critical in Linux? >> >> Switch XON/XOFF at all and try how it works. >> You have 256 bytes buffer, so you have place for 256 div 12 = 21 packets, >> assumming 10 bytes of data + CRLF. >> >> OR >> Another idea - try to send device's XON after first query... >> >> 12 bytes at 57600 there are small miliseconds... maybe Linux is to slow - >> what the computer is this - PC or small PDA, ARM? >> >> Mariusz >> >> ----- Original Message ----- >> *From:* Hybris >> *To:* rxtx at qbang.org >> *Sent:* Wednesday, September 15, 2010 1:56 PM >> *Subject:* Re: [Rxtx] XON XOFF under linux >> >> The protocol is not binary and the device works only that way. >> >> I'll do some of the checks you mentioned but it seems fair to me expecting >> rxtx to behave the same way on windows and linux. >> >> I recognize that it can also be a buffer problem, or a XON/XOFF value >> problem....unfortunately linux does not offer any decent tool for sniffing >> the serial at OS level as far as i know. >> >> 2010/9/15 M.Dec-GM >> >>> Hi, >>> Using XON-XOFF software handshake protocol has a some limitations - bytes >>> for XON and for XOFF are not usable, so you shouldn't transfer binary data >>> through channel. >>> This is why I am not using this protocol at all. >>> But it isn't answer yet :) >>> >>> Maybe this helps: >>> 1. Please check if codes for XON/XOFF are identical in host and client. >>> 2. I have met in the past COM tool for Win Delphi, where XON/XOFF should >>> be defined by user and I did a mistake - I have forgotten to switch >>> automatic XON/XOFF in tool, but both codes were 0x00 by default... >>> You know what it means when binary data were transmitted... crazy :). >>> 3. Maybe Trent knows more about XON/XOFF in RXTX, I may help on this way >>> only... >>> 4. Looking on the problem from another side - think if XON/XOFF is >>> necessary for now, maybe bigger buffer will be enough, or simply write >>> yourself the >>> service for XON/XOFF - this very easy, and you may use my examples for >>> this job. >>> There is enough to check XOFF in SerialReader and stop writing until XON >>> will come... >>> >>> Good luck :) >>> Mariusz >>> >>> >>> >>> >>> ----- Original Message ----- >>> *From:* Hybris >>> *To:* rxtx at qbang.org >>> *Sent:* Wednesday, September 15, 2010 12:46 PM >>> *Subject:* Re: [Rxtx] XON XOFF under linux >>> >>> Nobody can help on this? >>> >>> 2010/9/7 Hybris >>> >>>> Hi, >>>> i have a problem under Linux. >>>> I often used the library (last stable release 2.1) without any problem >>>> in this environment. >>>> >>>> Without any other clues at the moment i am blaming the fact i am >>>> talking a device that requires XON/XOFF as flow control method. A >>>> method i never used before. >>>> >>>> Under windows i have no problems, under Linux commands are received by >>>> the device but i do not get replies or i get truncated replies (log >>>> follows) >>>> >>>> I am using the seial port builtin the motherboard, no usb converters. >>>> >>>> I initialize the port this way: >>>> CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); >>>> serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); >>>> serialPort.setInputBufferSize(256); >>>> serialPort.setOutputBufferSize(256); >>>> serialPort.enableReceiveTimeout(1000); >>>> serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | >>>> RXTXPort.FLOWCONTROL_XONXOFF_OUT); >>>> serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, >>>> RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); >>>> >>>> The protocol used is an ascii protocol with CR/LF terminator for >>>> messages. >>>> >>>> The output i get on windows for a cycle of request/response (one per >>>> second) is this (>>> from PC to the device, <<< from device to PC): >>>> >>>> 2010-09-07 12.18.07: <<< 1TS000033 >>>> 2010-09-07 12.18.08: >>> 1TS >>>> 2010-09-07 12.18.08: <<< 1TS000033 >>>> 2010-09-07 12.18.09: >>> 1TS >>>> 2010-09-07 12.18.09: <<< 1TS000033 >>>> 2010-09-07 12.18.10: >>> 1TS >>>> 2010-09-07 12.18.10: <<< 1TS000033 >>>> 2010-09-07 12.18.11: >>> 1TS >>>> 2010-09-07 12.18.11: <<< 1TS000033 >>>> >>>> On linux instead i have this: >>>> >>>> 2010-09-07 12.16.40: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.42: >>> 1TS >>>> 2010-09-07 12.16.42: <<< 3 >>>> 2010-09-07 12.16.43: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.45: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.47: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.49: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.51: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.53: >>> 1TS >>>> 2010-09-07 12.16.53: <<< 3 >>>> 2010-09-07 12.16.54: >>> 1TS >>>> timeout >>>> 2010-09-07 12.16.56: >>> 1TS >>>> 2010-09-07 12.16.56: <<< 1TS000033 >>>> 2010-09-07 12.16.57: >>> 1TS >>>> 2010-09-07 12.16.58: <<< 3 >>>> 2010-09-07 12.16.59: >>> 1TS >>>> timeout >>>> 2010-09-07 12.17.01: >>> 1TS >>>> timeout >>>> >>>> Any ideas? >>>> >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Wed Sep 15 07:55:58 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 15:55:58 +0200 Subject: [Rxtx] JNA References: <4C8FD6B0.9070306@howardz.com><95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: Hi Steffen, > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports Currently I am using Windows application (USB CAN reader for my car) where is the default list of the ports (COM64 is the highest one). Additionally I am using a lot of USB dongles simultaneously (about 20, up to 4 in one of applications) and there is no way to remember which COM number has THIS dongle on laptop or on desktop or in another USB socket... The same with CAN reader... And therefore I am very happy when I see available ports only - the highest number of the COM which I have used in last weeks was COM249 :). Have you used such COM port number? :) I have had to clean registry quite often... I think that now you understand my point of view on hardcoded COM ports list :))) Regards Mariusz From tjarvi at qbang.org Wed Sep 15 07:36:32 2010 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 15 Sep 2010 07:36:32 -0600 (MDT) Subject: [Rxtx] JNA In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> References: <4C8FD6B0.9070306@howardz.com> <95E46F3E54BF4D77935D0B034703389C@mdam2> <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: On Wed, 15 Sep 2010, Steffen DETTMER wrote: > * M.Dec-GM wrote on Wed, Sep 15, 2010 at 07:48 +0200: >> Hi all, >> So - this:part looks crazy: >>> // In case of errors, list COM1 through COM9 - it is better than nothing. >>> h = new String[] {"COM1","COM2","COM3","COM4","COM5","COM6","COM7","COM8","COM9"}; >> >> What for > > maybe better: `a doubtful'? > >> list [...]: "it is better than nothing", >> if such list gives no useful information... >> >> Please try to connect to the port from this list.... "Better >> than nothing" is to write - No ports, List Error or something >> like that... > > Indeed the application shall have a way to notice the problem > that should never occure. Also, a better fallback probably would > be the classic port enumeration code (althrough I also dislike if > this `probing' modifies control lines of those ports; but I'm not > neutral here anyway, because I dislike such `browsing' stuff and > would prefere to be able to enter the port name to use, as used > to be on classic unices and even if the serial port happens to be > a terminal or even a FIFO, almost everything works). > > Also, it might be insufficient to present the list of currently > available serial ports, for example in a configuration dialog I > may wish to configure ports which currently are not connected. > AFAIK, this for example is simply not possible with windows > hardware device manager, because in case the USB device is not > plugged you have it in no list where you could click it; bad... > So I think a good application should allow users to specify ports > directly anyway and no such fallback would be required. > > But back to topic, in case /everything/ fails, having a default > list of `usual' port name IMHO does not seem too bad. Me, for > examples, knows many workstation installations with COM ports > usually ranging from COM1 to COM8, COM0 and COM9 are seen rarely, > so such a fallback could help the majority of users where both > registry lookup and `port probing' fail. Of course it is hard to > tell what will happen on systems of the windows users where > registry lookups fail, probably nothing will work anyway, but who > knows :) > I'd just add that laptops are the most common computer people use today and very few actually have serial ports out of the box. No ports available is a useful answer. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Wed Sep 15 08:04:50 2010 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 15 Sep 2010 17:04:50 +0300 Subject: [Rxtx] XON XOFF under linux In-Reply-To: Message-ID: > > it sends 5 bytes, \r\n are printed and the output goes on the next line as a > side effect (sorry if i did not point it out). > > anyway the code: > > sh.write("1TS\r\n"); > > where sh.write does this: > > public void write(String s) throws IOException { > ??????? debug(String.format(">>> %s", s)); > ??????? outputStream.write(s.getBytes()); > } Java doc for String.getBytes() says: "Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array." Could it be that the default charset on your Linux system is different from Windows and this messes things up? > > outputStream is a bare OutputStream obtained from the serial port > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent > > public String readLine() throws IOException { > ??????? String s = reader.readLine(); > ??????? debug(String.format("<<< %s", s)); > ??????? return s; > ??? } > > reader is a BufferedReader built around the serialport input stream > reader = new BufferedReader(new InputStreamReader(is)); > > Nothing strikes me as suspicious above. But I still do not understand this, you said (for Windows): >>> 2010-09-07 12.1807: <<< 1TS000033 >>> 2010-09-07 12.18.08: >>> 1TS >>> 2010-09-07 12.18.08: <<< 1TS000033 >>> 2010-09-07 12.18.09: >>> 1TS >>> 2010-09-07 12.18.09: <<< 1TS000033 >>> 2010-09-07 12.18.10: >>> 1TS >>> 2010-09-07 12.18.10: <<< 1TS000033 ' where does that '000033 come and why it is different in the Linux case? br Kusti From Steffen.DETTMER at ingenico.com Wed Sep 15 08:08:32 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:08:32 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: <20100915140832.GF7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > As i said under linux i do not have a powerful tool like portmon on > windows (funny because usually is the other way round) > The read and write is pretty simple could `strace -e open,read,write -p ' help maybe? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:12:49 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:12:49 +0200 Subject: [Rxtx] XON XOFF under linux References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2><1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <05754F9E14B746D1B81F2827F7E738F6@mdam2> Sorry, but finally I don't understand... You have written: ----> the device requires XON/XOFF I know it from tenths of years, but I have checked once again: http://en.wikipedia.org/wiki/Software_flow_control Flow control is necessary when one of the communication sides can't receive data because of somewhat... So if transmission is fast and short, and machines are fast, XON/XOFF signals NEVER occurs. Execptions....? ... exception I see now as possible one is the initalisation of the transmission, but in this case YOU should try to send XON. Mariusz From hybris0 at gmail.com Wed Sep 15 08:16:48 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:16:48 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: 2010/9/15 Kustaa Nyholm > > Could it be that the default charset on your Linux system is different from > Windows and this messes things up? > > yes it could but since i use only ASCII it could not. Anyway i just tested it and the list of bytes generated is correct so the problem is not there. > But I still do not understand this, you said (for Windows): [...] > > where does that '000033 come and why it is different in the Linux case? > > 1TS000033 is the reply from the device at the command 1TS the linux case is different imho because the flow control is messing things up....but i can't prove it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:19:37 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:19:37 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> Message-ID: <20100915141937.GG7681@elberon.bln.de.ingenico.com> * Hybris wrote on Wed, Sep 15, 2010 at 15:40 +0200: > And what about this problem - how it works WITHOUT XON/XOFF? I'm not sure if I understand the question correctly, but in case it helps: If you are able to always receive full speed (e.g. because on a fine PC) and you write slowing (some Thread.Sleep(50) per each few bytes or so), you should never need to send XOFF and the device should never need to do so; maybe you need to send XON once at the begin (if device starts in XOFF) but everything else should work `transparently' in this special case (i.e. PC is receiving fast but sending slowly). You told you're working on linux; here shell console windows (xterm etc) are XON/XOFF (CTRL-Q / CTRL-S), so you know how it works: as long as you don't press CTRL-S, text scrolls through. oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From hybris0 at gmail.com Wed Sep 15 08:26:58 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:26:58 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <05754F9E14B746D1B81F2827F7E738F6@mdam2> References: <248CDC29A3E14A589621FDEDFD942E6A@mdam2> <1CD57CB0C6974785BFAB43E383D60295@mdam2> <05754F9E14B746D1B81F2827F7E738F6@mdam2> Message-ID: i understand your point and i admit ignorance on how XON/XOFF worked.... i have to assume some things as blackboxes sometimes otherwise i'll go crazy i'll investigate further 2010/9/15 M.Dec-GM > Sorry, but finally I don't understand... > You have written: > ----> the device requires XON/XOFF > > I know it from tenths of years, but I have checked once again: > http://en.wikipedia.org/wiki/Software_flow_control > > Flow control is necessary when one of the communication sides can't receive > data because of somewhat... > So if transmission is fast and short, and machines are fast, XON/XOFF > signals NEVER occurs. > > Execptions....? > ... exception I see now as possible one is the initalisation of the > transmission, but in this case YOU should try to send XON. > > Mariusz > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hybris0 at gmail.com Wed Sep 15 08:29:08 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:29:08 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: <20100915140832.GF7681@elberon.bln.de.ingenico.com> References: <20100915140832.GF7681@elberon.bln.de.ingenico.com> Message-ID: yes it could but that call also traces operation on files etc. last time i tried the output was so bloated that i gave up but i should try again 2010/9/15 Steffen DETTMER > * Hybris wrote on Wed, Sep 15, 2010 at 14:42 +0200: > > As i said under linux i do not have a powerful tool like portmon on > > windows (funny because usually is the other way round) > > The read and write is pretty simple > > could `strace -e open,read,write -p ' help maybe? > > oki, > > Steffen > > > > About Ingenico: Ingenico is a leading provider of payment solutions, with > over 15 million terminals deployed in more than 125 countries. Its 2,850 > employees worldwide support retailers, banks and service providers to > optimize and secure their electronic payments solutions, develop their offer > of services and increase their point of sales revenue. More information on > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If > you are not the addressee or authorized to receive this for the addressee, > you must not use, copy, disclose or take any action based on this message or > any information herein. If you have received this message in error, please > advise the sender immediately by reply e-mail and delete this message. Thank > you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Wed Sep 15 08:32:12 2010 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 15 Sep 2010 16:32:12 +0200 Subject: [Rxtx] JNA In-Reply-To: References: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <20100915143212.GH7681@elberon.bln.de.ingenico.com> * M.Dec-GM wrote on Wed, Sep 15, 2010 at 15:55 +0200: > Additionally I am using a lot of USB dongles simultaneously > (about 20, up to 4 in one of applications) and there is no way > to remember which COM number has THIS dongle on laptop or on > desktop or in another USB socket... The same with CAN reader... > > And therefore I am very happy when I see available ports only - > the highest number of the COM which I have used in last weeks > was COM249 :). Have you used such COM port number? :) Yes, similar things happen with some USB terminals that have to reboot several time in a kind of loop for some test cases, but on linux the used device names were much more cryptic :-) Also, it even seems you can crash many PCs or their USB subsystems by pluging/unplugging and/or booting/rebooting and/or `USB-re-negiotiating' things simultanously/quickly/often enough... > I have had to clean registry quite often... > I think that now you understand my point of view on hardcoded > COM ports list :))) Yes, I do and of course you are right with your statements. I just wanted to point out that in case everything fails and the list that usually shows the available ports would be completely empty, because both methods of enumerating them failed, it could be useful in some circumstances to have then at least a list of COM1..COM10 instead of an empty one, especially in a `must not happen' case, but the application has a way to notice this of course (and I would never expect a library to perform such fallbacks unless explicitely documented - troubleshoting this would be a nightmare...). In other words, it could be considered a way to fail softer and/or to limit damage in some special cases, but as also told in this thread this should be configurable. Since the default should probably be `disabled', the whole feature is even a bit more doubtful, because in case the application is aware of this situation, it could implement a fallback (such as a text input dialog) anyway - this specific implementation surely would suit better to the applications situation. I just wanted to point out that there are situations in which a `better than nothing' fallback is suited, but I agree that this one may not being one of them (however, no need to call it with words, but the OP was even worse... but now again lets all be friends!). oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Wed Sep 15 08:40:31 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Wed, 15 Sep 2010 16:40:31 +0200 Subject: [Rxtx] XON XOFF under linux References: Message-ID: ----- Original Message ----- From: "Kustaa Nyholm" To: Sent: Wednesday, September 15, 2010 4:04 PM Subject: Re: [Rxtx] XON XOFF under linux > > on the reading side i use a buffered reader to read lines, the doc states that > a line is ended by \n or \r\n so it should be platform indepentent ^^^^^^ HERE may be the problem as well: "SHOULD BE" but in many cases ISN'T. Mariusz From adrian.crum at yahoo.com Wed Sep 15 08:49:02 2010 From: adrian.crum at yahoo.com (Adrian Crum) Date: Wed, 15 Sep 2010 07:49:02 -0700 (PDT) Subject: [Rxtx] Port Discovery/Enumeration (Was: JNA) In-Reply-To: <20100915132611.GE7681@elberon.bln.de.ingenico.com> Message-ID: <582091.78813.qm@web63105.mail.re1.yahoo.com> --- On Wed, 9/15/10, Steffen DETTMER wrote: > Indeed the application shall have a way to notice the > problem > that should never occure. Also, a better fallback probably > would > be the classic port enumeration code (althrough I also > dislike if > this `probing' modifies control lines of those ports; but > I'm not > neutral here anyway, because I dislike such `browsing' > stuff and > would prefere to be able to enter the port name to use, as > used > to be on classic unices and even if the serial port happens > to be > a terminal or even a FIFO, almost everything works). Let's not forget that you can specify ports in the properties file. Automatic port discovery and enumeration is not reliable and it has bad side-effects. Improving the port discovery/enumeration code is a worthwhile goal, but in the end, a user can always specify the ports they want to use in the properties file. To me, that seems like a universally acceptable fallback method. -Adrian From hybris0 at gmail.com Wed Sep 15 08:50:23 2010 From: hybris0 at gmail.com (Hybris) Date: Wed, 15 Sep 2010 16:50:23 +0200 Subject: [Rxtx] XON XOFF under linux In-Reply-To: References: Message-ID: ok guys.... now i am pissed off i developed with this thing about 4 days......compiling on linux and hell testing in windows because of this problem i managed to finish my work and happily thrown it in his box for future use under, fortunately, windows you gave me some hints, you gave me some things to think about so i take the whole stuff out of his box again, reattach all those nice connections it has and what happens it all works without changing a line of code sometimes things like this happen to me and i really do not have answers it's running now smoothly... i can't believe all the time i spent in trying to figure out what was wrong and probably i'll never know :( thanks anyway 2010/9/7 Hybris > Hi, > i have a problem under Linux. > I often used the library (last stable release 2.1) without any problem > in this environment. > > Without any other clues at the moment i am blaming the fact i am > talking a device that requires XON/XOFF as flow control method. A > method i never used before. > > Under windows i have no problems, under Linux commands are received by > the device but i do not get replies or i get truncated replies (log > follows) > > I am using the seial port builtin the motherboard, no usb converters. > > I initialize the port this way: > CommPortIdentifier portId = CommPortIdentifier.getPortIdentifier(port); > serialPort = (RXTXPort)portId.open(this.getClass().getName(), 50); > serialPort.setInputBufferSize(256); > serialPort.setOutputBufferSize(256); > serialPort.enableReceiveTimeout(1000); > serialPort.setFlowControlMode(RXTXPort.FLOWCONTROL_XONXOFF_IN | > RXTXPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setSerialPortParams(57600, RXTXPort.DATABITS_8, > RXTXPort.STOPBITS_1, RXTXPort.PARITY_NONE); > > The protocol used is an ascii protocol with CR/LF terminator for messages. > > The output i get on windows for a cycle of request/response (one per > second) is this (>>> from PC to the device, <<< from device to PC): > > 2010-09-07 12.18.07: <<< 1TS000033 > 2010-09-07 12.18.08: >>> 1TS > 2010-09-07 12.18.08: <<< 1TS000033 > 2010-09-07 12.18.09: >>> 1TS > 2010-09-07 12.18.09: <<< 1TS000033 > 2010-09-07 12.18.10: >>> 1TS > 2010-09-07 12.18.10: <<< 1TS000033 > 2010-09-07 12.18.11: >>> 1TS > 2010-09-07 12.18.11: <<< 1TS000033 > > On linux instead i have this: > > 2010-09-07 12.16.40: >>> 1TS > timeout > 2010-09-07 12.16.42: >>> 1TS > 2010-09-07 12.16.42: <<< 3 > 2010-09-07 12.16.43: >>> 1TS > timeout > 2010-09-07 12.16.45: >>> 1TS > timeout > 2010-09-07 12.16.47: >>> 1TS > timeout > 2010-09-07 12.16.49: >>> 1TS > timeout > 2010-09-07 12.16.51: >>> 1TS > timeout > 2010-09-07 12.16.53: >>> 1TS > 2010-09-07 12.16.53: <<< 3 > 2010-09-07 12.16.54: >>> 1TS > timeout > 2010-09-07 12.16.56: >>> 1TS > 2010-09-07 12.16.56: <<< 1TS000033 > 2010-09-07 12.16.57: >>> 1TS > 2010-09-07 12.16.58: <<< 3 > 2010-09-07 12.16.59: >>> 1TS > timeout > 2010-09-07 12.17.01: >>> 1TS > timeout > > Any ideas? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:18:31 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:18:31 -0400 Subject: [Rxtx] Linux build problem Message-ID: Hi I was wondering if anyone could shed some light on why I'm having the following build problem on Linux. I usually build on windows so this is a bit of a departure for me. I'm trying to build 2.2pre2 (with a few patches) but it doesn't appear like the patches are at fault here. I had a quick look through the *.in files but nothing obvious came to light. Any help would be appreciated. John Coffey $ ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu configure: WARNING: Trying libtool. If the following fails install libtool checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... yes checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for gfortran option to produce PIC... -fPIC checking if gfortran PIC flag -fPIC works... yes checking if gfortran supports -c -o file.o... yes checking whether the gfortran linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking dependency style of gcc... none checking dependency style of g++... none checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking sys/fcntl.h usability... yes checking sys/fcntl.h presence... yes checking for sys/fcntl.h... yes checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/signal.h usability... yes checking sys/signal.h presence... yes checking for sys/signal.h... yes checking signal.h usability... yes checking signal.h presence... yes checking for signal.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking whether gcc needs -traditional... no checking whether to enable maintainer-specific portions of Makefiles... no checking for xcode-select... no checking java.home /usr/java/jdk1.6.0_21/jre adjusted java.home is /usr/java/jdk1.6.0_21 checking os.name Linux checking os.arch i386 checking java.vendor Sun Microsystems Inc. checking java.version 1.6.0_21 checking os.version 2.6.27.25-170.2.72.fc10.i686 configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:11:59] $ make /usr/java/jdk1.6.0_21/bin/javac -classpath .:/home/john/main/javacode/rxtx-devel:/home/john/main/javacode/rxtx-devel/src: -d /home/john/main/javacode/rxtx-devel/ -O -source 1.3 -target 1.3 /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortEnumerator.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortIdentifier.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/CommPortOwnershipListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Configure.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2C.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/I2CPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/LPRPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/NoSuchPortException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/ParallelPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortAlreadyClosedException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/PortInUseException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Raw.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RawPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485PortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RS485Port.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXCommDriver.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/RXTXVersion.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEvent.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPortEventListener.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialPort.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnsupportedCommOperationException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/UnSupportedLoggerException.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/Zystem.java /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:138: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String IOException ex = new IOException( String.format( "Port is in use: %s ", e.currentOwner ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:164: cannot find symbol symbol : method format(java.lang.String,java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "RXTX: java %s, native %s", gnu.io.RXTXVersion.getVersion(), gnu.io.RXTXVersion.nativeGetVersion() ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:168: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.out.println( String.format( "Connecting to serial port (%s)..", serialPortName ) ); ^ /home/john/main/javacode/rxtx-devel/./src/gnu/io/SerialReconnectDemo.java:186: cannot find symbol symbol : method format(java.lang.String,java.lang.String) location: class java.lang.String System.err.println( String.format( "IO error: %s", e.getMessage() ) ); ^ 4 errors make: *** [/home/john/main/javacode/rxtx-devel/gnu/io/CommDriver.class] Error 1 [john at geiswbuild1 ~/main/javacode/rxtx-devel Wed Sep 15 18:12:37] -------------- next part -------------- An HTML attachment was scrubbed... URL: From hontvari at flyordie.com Wed Sep 15 16:28:42 2010 From: hontvari at flyordie.com (=?UTF-8?B?SG9udHbDoXJpIErDs3pzZWYgTGV2ZW50ZQ==?=) Date: Thu, 16 Sep 2010 00:28:42 +0200 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C903D25.5030301@flyordie.com> References: <4C903D25.5030301@flyordie.com> Message-ID: <4C91489A.4080304@flyordie.com> I have found a way to make it work. If the code changes flow control from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it immediately receive both the command responses and the data sent by the remote modem. It is still unclear why setting the flow control makes any difference, considering that the same procedure works in the terminal even if the terminal is set to "no flow control" or XON/XOFF flow control. On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > I want to start a data connection through a mobile phone, acting as a > modem, using AT commands. It does work in a terminal as expected. > > There is a strange behavior when I do the same thing through RXTX. The > modem should respond to the dial (ATD...) command with a CONNECT ... > message, after it successfully connected to the remote modem. It does > respond. But my code receive this message and any data the remote > modem sends only after the data transfer is completed and the modems > disconnects or after the modem temporarily goes into command state > during the session. > > There is a log below and I attached the test class which produced it. > > For the record: The phone is Siemens C55 connected through an > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > 377 Flow control: 0 > 1379 Event: Output buffer is empty (false->true) > 1380 Sent: atd+36304696729\r > 1381 Event: Output buffer is empty (false->true) > 1428 Event: Data available (false->true) > 1528 Read: atd+36304696729\r > 20758 Event: Carrier detect (false->true) > 22800 Event: Output buffer is empty (false->true) > 22800 Sent: Hello World!\r\n > 22801 Event: Output buffer is empty (false->true) > 22801 Sent: Lets go chat!\r\n > 22805 Event: Output buffer is empty (false->true) > 32802 Event: Output buffer is empty (false->true) > 32802 Sent: +++ > 32803 Event: Output buffer is empty (false->true) > 33808 Event: Data available (false->true) > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > \r\r\nOK\r\n > 35803 Event: Output buffer is empty (false->true) > 35803 Sent: ath\r > 35805 Event: Output buffer is empty (false->true) > 35860 Event: Data available (false->true) > 35962 Read: ath\r > 36266 Event: Data available (false->true) > 36367 Read: \r\nOK\r\n > 36368 Event: Carrier detect (true->false) > 37803 The End > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnco3 at gmail.com Wed Sep 15 16:50:26 2010 From: johnco3 at gmail.com (John Coffey) Date: Wed, 15 Sep 2010 18:50:26 -0400 Subject: [Rxtx] Linux build problem Message-ID: Fixed, sorry my bad! I had an extraneous file in my build which the auto-conf script was picking up. It's compiling now. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at g0poy.com Wed Sep 15 18:33:38 2010 From: andy at g0poy.com (Andy Eskelson) Date: Thu, 16 Sep 2010 01:33:38 +0100 Subject: [Rxtx] input from a remote modem delayed until hangup In-Reply-To: <4C91489A.4080304@flyordie.com> References: <4C903D25.5030301@flyordie.com> <4C91489A.4080304@flyordie.com> Message-ID: <20100916013338.2a7f78c7@g0poy-server.site> It is possible that by setting the hardware flow control it may be setting the correct conditions for the data flow to start. My first thought would be to hang a breakout box on the cable and see what (if anything) changes It would not be the first time I've found that a device set to Xon-Xoff or even no flow control needing to see the correct conditions on the hardware control lines before it would start to work correctly. windows Hyperterm is one such troublemaker, sometimes and I've never worked out what causes it, sometimes it just stops working or will not start. The only way to wake it up is to fiddle with the control lines, and eventually it starts. One company I worked for gave up recommending it as a terminal, due to the number of help calls we got, and we switched to Tera Term, and the problems went away. Andy On Thu, 16 Sep 2010 00:28:42 +0200 Hontv?ri J?zsef Levente wrote: > I have found a way to make it work. If the code changes flow control > from the default FLOWCONTROL_NONE to FLOWCONTROL_RTSCTS_IN, then it > immediately receive both the command responses and the data sent by the > remote modem. > > It is still unclear why setting the flow control makes any difference, > considering that the same procedure works in the terminal even if the > terminal is set to "no flow control" or XON/XOFF flow control. > > > On 2010.09.15. 5:27, Hontv?ri J?zsef Levente wrote: > > I want to start a data connection through a mobile phone, acting as a > > modem, using AT commands. It does work in a terminal as expected. > > > > There is a strange behavior when I do the same thing through RXTX. The > > modem should respond to the dial (ATD...) command with a CONNECT ... > > message, after it successfully connected to the remote modem. It does > > respond. But my code receive this message and any data the remote > > modem sends only after the data transfer is completed and the modems > > disconnects or after the modem temporarily goes into command state > > during the session. > > > > There is a log below and I attached the test class which produced it. > > > > For the record: The phone is Siemens C55 connected through an > > USB-Serial converter data cable, the OS is Windows 7 - 32 bit. > > > > > > > > > > Stable Library > > ========================================= > > Native lib Version = RXTX-2.1-7 > > Java lib Version = RXTX-2.1-7 > > 377 Flow control: 0 > > 1379 Event: Output buffer is empty (false->true) > > 1380 Sent: atd+36304696729\r > > 1381 Event: Output buffer is empty (false->true) > > 1428 Event: Data available (false->true) > > 1528 Read: atd+36304696729\r > > 20758 Event: Carrier detect (false->true) > > 22800 Event: Output buffer is empty (false->true) > > 22800 Sent: Hello World!\r\n > > 22801 Event: Output buffer is empty (false->true) > > 22801 Sent: Lets go chat!\r\n > > 22805 Event: Output buffer is empty (false->true) > > 32802 Event: Output buffer is empty (false->true) > > 32802 Sent: +++ > > 32803 Event: Output buffer is empty (false->true) > > 33808 Event: Data available (false->true) > > 33959 Read: \r\nCONNECT 9600/RLP\r\nRemote modem: Hi RXTX list! > > \r\r\nOK\r\n > > 35803 Event: Output buffer is empty (false->true) > > 35803 Sent: ath\r > > 35805 Event: Output buffer is empty (false->true) > > 35860 Event: Data available (false->true) > > 35962 Read: ath\r > > 36266 Event: Data available (false->true) > > 36367 Read: \r\nOK\r\n > > 36368 Event: Carrier detect (true->false) > > 37803 The End > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > From lucio at sulweb.org Fri Sep 17 06:18:58 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 14:18:58 +0200 Subject: [Rxtx] well known disconnect and crash problem Message-ID: <201009171418.58406.lucio@sulweb.org> Hello *, I'd need a version of rxtx without the "crash on disconnect" problem. I've read a few posts claiming a java-only solution, while some other offer a patch, e.g. the one attached to bug#144. What's the best way to go? Has 2.2pre2 the same problem? @Adrian Crum: do you think the rewrite is stable enough for simple reading from a single port on Linux and Windows in a production app? Thanks in advance Lucio. From mariusz.dec at gmail.com Fri Sep 17 08:14:29 2010 From: mariusz.dec at gmail.com (M.Dec-GM) Date: Fri, 17 Sep 2010 16:14:29 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> Message-ID: ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 2:18 PM Subject: [Rxtx] well known disconnect and crash problem > Hello *, > > I'd need a version of rxtx without the "crash on disconnect" problem. I've At first read carefully thread "RXTX - USB disconnecting safe and fast data transfer to app" And note that there is written about RXTX and USB disconnect. There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works in many cases. Mariusz From lucio at sulweb.org Fri Sep 17 09:07:11 2010 From: lucio at sulweb.org (Lucio Crusca) Date: Fri, 17 Sep 2010 17:07:11 +0200 Subject: [Rxtx] well known disconnect and crash problem In-Reply-To: References: <201009171418.58406.lucio@sulweb.org> Message-ID: <201009171707.11477.lucio@sulweb.org> In data venerd? 17 settembre 2010 16:14:29, M.Dec-GM ha scritto: > ----- Original Message ----- > At first read carefully thread "RXTX - USB disconnecting safe and fast data > transfer to app" And note that there is written about RXTX and USB > disconnect. Sometimes I feel the general attitude on this list not being very friendly, but I can't bet, 'cause it may very well be my poor english knowledge... never mind, could you please drop me a pointer to that thread? I subscribed to this list only 2 months ago and I have no idea where to start looking for it in the list archives. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Thanks again, Lucio. From mariusz.dec at gmail.com Fri Sep 17 11:32:32 2010 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 17 Sep 2010 19:32:32 +0200 Subject: [Rxtx] well known disconnect and crash problem References: <201009171418.58406.lucio@sulweb.org> <201009171707.11477.lucio@sulweb.org> Message-ID: <986039CEE912457F87F43A281ED43768@mdam2> ----- Original Message ----- From: "Lucio Crusca" To: Sent: Friday, September 17, 2010 5:07 PM There are main http://mailman.qbang.org/pipermail/rxtx/2010-September/7047577.html and next one with small improvement. > There is NO speciual version of RXTX, only Java and RXTX 2.2pre2 and works > in many cases. Sorry to disturb you further, but does that mean that 2.2pre2 is better than 2.1-7 in this regard? Almost 100 percent probability: - YES. But you have to good understand comments inside examples to adapt it for your code!!! In some places it looks and in fact is a bit complicated but ... works. Mariusz From namanvit at gmail.com Tue Sep 21 04:18:01 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 15:48:01 +0530 Subject: [Rxtx] error using nativelib in jnlp Message-ID: Hello, I am trying to make a COM reader in java using jnlp. So I have the files RXTXcomm.jar, rxtxwin32.dll. I have made a jar of my nativedlll -> rxtxSerial.dll.jar so my jnlp looks like: new naman.jain new new Code: I have already signed all the three jars involved here using the same certificate. Now I run it but it shows a error: Use of native libraries require unrestricted acces to the system. JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) at com.sun.javaws.Launcher.downloadResources(Unknown Source) at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) at com.sun.javaws.Launcher.launch(Unknown Source) at com.sun.javaws.Main.launchApp(Unknown Source) at com.sun.javaws.Main.continueInSecureThread(Unknown Source) at com.sun.javaws.Main$1.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Could anyone please explain what could be the issue? I tried reading other related posts but could not exactly understand the cause of the problem. Regards Naman From george.dma at gmail.com Tue Sep 21 04:54:00 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 13:54:00 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 1:18 PM, naman jain wrote: > Hello, > > > I am trying to make a COM reader in java using jnlp. > > So I have the files RXTXcomm.jar, rxtxwin32.dll. > I have made a jar of my nativedlll -> rxtxSerial.dll.jar > > so my jnlp looks like: > > > ? ? > ? ? ? ?new > ? ? ? ?naman.jain > ? ? ? ? > ? ? ? ?new > ? ? ? ?new > > ? ? > > > ? ? > > > ? ? > ? ? ? ? > > > ? ? > > ? ? > > > Code: > > > > > > > > I have already signed all the three jars involved here using the same > certificate. > > Now I run it but it shows a error: > > Use of native libraries require unrestricted acces to the system. > JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] > ? at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) > ? at com.sun.javaws.Launcher.downloadResources(Unknown Source) > ? at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) > ? at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) > ? at com.sun.javaws.Launcher.launch(Unknown Source) > ? at com.sun.javaws.Main.launchApp(Unknown Source) > ? at com.sun.javaws.Main.continueInSecureThread(Unknown Source) > ? at com.sun.javaws.Main$1.run(Unknown Source) > ? at java.lang.Thread.run(Unknown Source) > > Could anyone please explain what could be the issue? > I tried reading other related posts but could not exactly understand > the cause of the problem. > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, I have had issues with native dlls and JNLP a long time ago and it is quite tricky to work. As you know programs running from JNLPs are subject to strict security which includes signing the jar file. Now you said you signed the jars so there is only 1 thing left to do. You have to explicitly tell the JNLP that the program needs unrestricted access to the system by defining a tag. Try adding this to your JNLP before the resources section. This gives full access of the jnlp app to the system. To fine tune permissions and access you should look at creating policy files which you can find at http://download.oracle.com/javase/1.4.2/docs/guide/security/permissions.html http://download-llnw.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html Hope this helps. -- George H george.dma at gmail.com From george.dma at gmail.com Tue Sep 21 04:54:00 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 13:54:00 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 1:18 PM, naman jain wrote: > Hello, > > > I am trying to make a COM reader in java using jnlp. > > So I have the files RXTXcomm.jar, rxtxwin32.dll. > I have made a jar of my nativedlll -> rxtxSerial.dll.jar > > so my jnlp looks like: > > > ? ? > ? ? ? ?new > ? ? ? ?naman.jain > ? ? ? ? > ? ? ? ?new > ? ? ? ?new > > ? ? > > > ? ? > > > ? ? > ? ? ? ? > > > ? ? > > ? ? > > > Code: > > > > > > > > I have already signed all the three jars involved here using the same > certificate. > > Now I run it but it shows a error: > > Use of native libraries require unrestricted acces to the system. > JNLPException[category: Security Error : Exception: null : LaunchDesc: null ] > ? at com.sun.javaws.LaunchDownload.checkJNLPSecurity(Unknown Source) > ? at com.sun.javaws.Launcher.downloadResources(Unknown Source) > ? at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source) > ? at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source) > ? at com.sun.javaws.Launcher.launch(Unknown Source) > ? at com.sun.javaws.Main.launchApp(Unknown Source) > ? at com.sun.javaws.Main.continueInSecureThread(Unknown Source) > ? at com.sun.javaws.Main$1.run(Unknown Source) > ? at java.lang.Thread.run(Unknown Source) > > Could anyone please explain what could be the issue? > I tried reading other related posts but could not exactly understand > the cause of the problem. > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Hi, I have had issues with native dlls and JNLP a long time ago and it is quite tricky to work. As you know programs running from JNLPs are subject to strict security which includes signing the jar file. Now you said you signed the jars so there is only 1 thing left to do. You have to explicitly tell the JNLP that the program needs unrestricted access to the system by defining a tag. Try adding this to your JNLP before the resources section. This gives full access of the jnlp app to the system. To fine tune permissions and access you should look at creating policy files which you can find at http://download.oracle.com/javase/1.4.2/docs/guide/security/permissions.html http://download-llnw.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html Hope this helps. -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 05:22:54 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 16:52:54 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > I have had issues with native dlls and JNLP a long time ago and it is > quite tricky to work. As you know programs running from JNLPs are > subject to strict security which includes signing the jar file. Now > you said you signed the jars so there is only 1 thing left to do. > > You have to explicitly tell the JNLP that the program needs > unrestricted access to the system by defining a tag. Try > adding this to your JNLP before the resources section. > > > ? ? ? > Thanks for that. I put that and that error goes off. Though another ones comes in. I looks like really difficult to get it through :). now i get a error that the Jar resources in the jnlp file are not signed by same certificate. This looks a familiar error, But I have signed all three myself with a same certificate. According to my understanding, The problem should be with lib/RXTXcomm.jar as it is a third party jar that I downloaded. So is it signed by some other certificate beforehand. what do we do in such cases, I saw people writing somewher to make a seperate jnlp for RXTXcomm.jar ? Your comments on that. Regards Naman From george.dma at gmail.com Tue Sep 21 05:33:11 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 14:33:11 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 2:22 PM, naman jain wrote: >> I have had issues with native dlls and JNLP a long time ago and it is >> quite tricky to work. As you know programs running from JNLPs are >> subject to strict security which includes signing the jar file. Now >> you said you signed the jars so there is only 1 thing left to do. >> >> You have to explicitly tell the JNLP that the program needs >> unrestricted access to the system by defining a tag. Try >> adding this to your JNLP before the resources section. >> >> >> ? ? ? >> > > Thanks for that. I put that and that error goes off. Though another > ones comes in. > I looks like really difficult to get it through :). > > now i get a error that the > Jar resources in the jnlp file are not signed by same certificate. > > This looks a familiar error, But I have signed all three myself with a > same certificate. > According to my understanding, The problem should be with > lib/RXTXcomm.jar as it is a third party jar that > I downloaded. So is it signed by some other certificate beforehand. > > what do we do in such cases, I saw people writing somewher to make a > seperate jnlp for > RXTXcomm.jar ? > > Your comments on that. > > Regards > Naman Good to hear that the error went away. Umm yes I have had this error you are talking about. What I have done in that case was sign the jar files with my certificate. Note that where I was working we were distributing java programs via JNLP internally on our WAN so it was nothing anyone outside the company would use. I would even remove other certificates from jar files and replace them with our own, this was a problem I had when I jar file was signed by 2 different people. So try to sign the RXTXcomm.jar and see if that solves your problem. I always go by the rule, First make it work, then make it work better ;) -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 06:36:26 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 18:06:26 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > Good to hear that the error went away. > > Umm yes I have had this error you are talking about. What I have done > in that case was sign the jar files with my certificate. Note that > where I was working we were distributing java programs via JNLP > internally on our WAN so it was nothing anyone outside the company > would use. I would even remove other certificates from jar files and > replace them with our own, this was a problem I had when I jar file > was signed by 2 different people. > > So try to sign the RXTXcomm.jar and see if that solves your problem. > > I always go by the rule, First make it work, then make it work better ;) going by your rule :) -> 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error that in a jnlp, jar have different signature. 2. I dont know how to unsign a jar, so I created seperate jnlp's for each jar, and added as extension, in the main jnlp file. That works :) 3) Now I am looking for improvements. How do we unsign a already signed third party jar file. saw some ANT(?) scripts, but could make little sense from that. ex: http://frank.neatstep.com/node/29 Thanks! Regards Naman From george.dma at gmail.com Tue Sep 21 06:49:07 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 15:49:07 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 3:36 PM, naman jain wrote: >> Good to hear that the error went away. >> >> Umm yes I have had this error you are talking about. What I have done >> in that case was sign the jar files with my certificate. Note that >> where I was working we were distributing java programs via JNLP >> internally on our WAN so it was nothing anyone outside the company >> would use. I would even remove other certificates from jar files and >> replace them with our own, this was a problem I had when I jar file >> was signed by 2 different people. >> >> So try to sign the RXTXcomm.jar and see if that solves your problem. >> >> I always go by the rule, First make it work, then make it work better ;) > > going by your rule :) ?-> > > 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error > that in a jnlp, jar have different signature. > > 2. I dont know how to unsign a jar, so I created seperate jnlp's for > each jar, and added as extension, > in the main jnlp file. > > > > > > > > > > That works :) > > 3) Now I am looking for improvements. How do we unsign a already > signed third party jar file. > saw some ANT(?) ?scripts, but could make little sense from that. > ?ex: http://frank.neatstep.com/node/29 > > Thanks! > > Regards > Naman Cool. When a jar is signed there are some extra files added inside the manifest folder, I believe. You could use that link, I used to just open the jar file with WinZIP and just delete the certificates in the manifest. And then sign the jar so its has only 1 signature. Though doing the extensions is more proper to show that your RXTXcomm jar came from a credible authority. Whatever you security needs are go for it. -- George H george.dma at gmail.com From namanvit at gmail.com Tue Sep 21 07:03:33 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 18:33:33 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > Cool. > > When a jar is signed there are some extra files added inside the > manifest folder, I believe. You could use that link, I used to just > open the jar file with WinZIP and just delete the certificates in the > manifest. And then sign the jar so its has only 1 signature. Though > doing the extensions is more proper to show that your RXTXcomm jar > came from a credible authority. Whatever you security needs are go for > it. Thanks a ton ! I ll check it out. From george.dma at gmail.com Tue Sep 21 07:10:20 2010 From: george.dma at gmail.com (George H) Date: Tue, 21 Sep 2010 16:10:20 +0300 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: On Tue, Sep 21, 2010 at 3:36 PM, naman jain wrote: >> Good to hear that the error went away. >> >> Umm yes I have had this error you are talking about. What I have done >> in that case was sign the jar files with my certificate. Note that >> where I was working we were distributing java programs via JNLP >> internally on our WAN so it was nothing anyone outside the company >> would use. I would even remove other certificates from jar files and >> replace them with our own, this was a problem I had when I jar file >> was signed by 2 different people. >> >> So try to sign the RXTXcomm.jar and see if that solves your problem. >> >> I always go by the rule, First make it work, then make it work better ;) > > going by your rule :) ?-> > > 1. signed a already signed RXTXcom.jar, but didnt work out. Shows same error > that in a jnlp, jar have different signature. > > 2. I dont know how to unsign a jar, so I created seperate jnlp's for > each jar, and added as extension, > in the main jnlp file. > > > > > > > > > > That works :) > > 3) Now I am looking for improvements. How do we unsign a already > signed third party jar file. > saw some ANT(?) ?scripts, but could make little sense from that. > ?ex: http://frank.neatstep.com/node/29 > > Thanks! > > Regards > Naman > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > btw, that un-sign jar ant-script all it basically does is unjars the jar file in a directory. Deletes all files *.SF *.DSA *.RSA and then re-jars everything and signs the jar. So you can do this manually or use the script. From namanvit at gmail.com Tue Sep 21 08:37:04 2010 From: namanvit at gmail.com (naman jain) Date: Tue, 21 Sep 2010 20:07:04 +0530 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > btw, that un-sign jar ant-script all it basically does is unjars the > jar file in a directory. Deletes all files *.SF *.DSA *.RSA and then > re-jars everything and signs the jar. So you can do this manually or > use the script. Ohkay. I get it. From bschlining at gmail.com Tue Sep 21 09:59:59 2010 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 21 Sep 2010 08:59:59 -0700 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: > > I am trying to make a COM reader in java using jnlp. > > I use rxtx in JNLP files with no problems. Here's the steps: 1) Jar up your dll (I'm calling *rxtx-native-windows.jar*) 2) Sign the jar containing the DLL 3) Add the following to your JNLP: 4) Also add this to your JNLP Cheers -- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining bschlining at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bschlining at gmail.com Tue Sep 21 10:02:17 2010 From: bschlining at gmail.com (Brian Schlining) Date: Tue, 21 Sep 2010 09:02:17 -0700 Subject: [Rxtx] error using nativelib in jnlp In-Reply-To: References: Message-ID: